.. |
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 |