..
3Dvisualize
removed useless grain selection option (--grain)
2011-05-26 09:44:10 +00:00
colorMap.config
added possibility to select predefined colorscheme from config file
2011-02-04 09:36:26 +00:00
fftw3.f
tried to implement an inverse reconstruction, meaning to calculate an average deformation gradient from the 8 cornes of a node in reference and current configuration. Not working yet.
2011-02-21 16:30:18 +00:00
gmsh_colormapConstantHue.py
---had some problems with svn, hope everything is ok now---
2011-01-05 14:53:31 +00:00
gmsh_colormapOppositeColors.py
---had some problems with svn, hope everything is ok now---
2011-01-05 14:53:31 +00:00
libfftw3.a
tried to implement an inverse reconstruction, meaning to calculate an average deformation gradient from the 8 cornes of a node in reference and current configuration. Not working yet.
2011-02-21 16:30:18 +00:00
make_postprocessingMath
moved setup scripts back to subdirs where they are needed
2011-03-22 15:42:53 +00:00
mentat_colorMap
fixed bug when no argument was supplied
2011-02-18 09:02:29 +00:00
paraview_colormapConstantHue.py
---had some problems with svn, hope everything is ok now---
2011-01-05 14:53:31 +00:00
paraview_colormapOppositeColors.py
---had some problems with svn, hope everything is ok now---
2011-01-05 14:53:31 +00:00
postResults
fixed a nasty bug in reading the header of spectral files
2011-06-21 12:38:58 +00:00
postprocessingMath.f90
corrected mixup of Fortran (1,2,3,...) indexing to Python (0,1,2,...) style.
2011-04-14 10:11:23 +00:00
postprocessingMath.pyf
tried to implement an inverse reconstruction, meaning to calculate an average deformation gradient from the 8 cornes of a node in reference and current configuration. Not working yet.
2011-02-21 16:30:18 +00:00
spectral_iterationCount
now reports over all loadcases present in the output file, not just a selected one...
2011-06-15 18:14:05 +00:00
spectral_post.py
some polishing for single precision version.
2011-02-25 12:41:46 +00:00
spectral_post_single.py
removed all math functions only for double precision by the more flexible counterpart, e.g. "dsqrt --> sqrt", "dsin --> sin". Should not cause any harm, as long as "implicit none" is used.
2011-02-25 09:25:53 +00:00