DAMASK_EICMD/processing/post
Martin Diehl 75e20dffb7 corrected version conflict 2011-11-17 21:36:56 +00:00
..
3Dvisualize.py after a somewhat lengthy discussion with Philip about usability and developability and general file-naming philosophy we think that we found a compromise on the "to-dot-py or not-to-dot-py" issue: 2011-11-09 15:37:45 +00:00
addCauchy.py after a somewhat lengthy discussion with Philip about usability and developability and general file-naming philosophy we think that we found a compromise on the "to-dot-py or not-to-dot-py" issue: 2011-11-09 15:37:45 +00:00
addCompatibilityMismatch.py after a somewhat lengthy discussion with Philip about usability and developability and general file-naming philosophy we think that we found a compromise on the "to-dot-py or not-to-dot-py" issue: 2011-11-09 15:37:45 +00:00
addDeterminant.py after a somewhat lengthy discussion with Philip about usability and developability and general file-naming philosophy we think that we found a compromise on the "to-dot-py or not-to-dot-py" issue: 2011-11-09 15:37:45 +00:00
addDivergence.py after a somewhat lengthy discussion with Philip about usability and developability and general file-naming philosophy we think that we found a compromise on the "to-dot-py or not-to-dot-py" issue: 2011-11-09 15:37:45 +00:00
addMises.py after a somewhat lengthy discussion with Philip about usability and developability and general file-naming philosophy we think that we found a compromise on the "to-dot-py or not-to-dot-py" issue: 2011-11-09 15:37:45 +00:00
addNorm.py after a somewhat lengthy discussion with Philip about usability and developability and general file-naming philosophy we think that we found a compromise on the "to-dot-py or not-to-dot-py" issue: 2011-11-09 15:37:45 +00:00
addStrainTensors.py after a somewhat lengthy discussion with Philip about usability and developability and general file-naming philosophy we think that we found a compromise on the "to-dot-py or not-to-dot-py" issue: 2011-11-09 15:37:45 +00:00
averageDown.py after a somewhat lengthy discussion with Philip about usability and developability and general file-naming philosophy we think that we found a compromise on the "to-dot-py or not-to-dot-py" issue: 2011-11-09 15:37:45 +00:00
colorMap.config added option to output RGB palette on terminal 2011-10-20 11:59:15 +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
make_postprocessingMath corrected version conflict 2011-11-17 21:36:56 +00:00
mentat_colorMap.py after a somewhat lengthy discussion with Philip about usability and developability and general file-naming philosophy we think that we found a compromise on the "to-dot-py or not-to-dot-py" issue: 2011-11-09 15:37:45 +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.py after a somewhat lengthy discussion with Philip about usability and developability and general file-naming philosophy we think that we found a compromise on the "to-dot-py or not-to-dot-py" issue: 2011-11-09 15:37:45 +00:00
postprocessingMath.f90 compile test is now at least compiling. still comparison to reference results has to be done 2011-11-11 15:06:33 +00:00
postprocessingMath.pyf debugging of addDebugInformation (now working, but not tested in detail) 2011-08-25 18:18:38 +00:00
spectral_convergence.py after a somewhat lengthy discussion with Philip about usability and developability and general file-naming philosophy we think that we found a compromise on the "to-dot-py or not-to-dot-py" issue: 2011-11-09 15:37:45 +00:00
spectral_iterationCount.py after a somewhat lengthy discussion with Philip about usability and developability and general file-naming philosophy we think that we found a compromise on the "to-dot-py or not-to-dot-py" issue: 2011-11-09 15:37:45 +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