a0f1509045
full out of source build
...
no temporary variables appear in src if following cmake procedure
2020-03-09 13:55:28 +01:00
0b340a6d42
Merge branch 'less-public-variables' into development
2020-03-09 11:25:35 +01:00
c4a0bf62f0
UTF signs for clearer documentation
2020-03-02 15:30:39 +01:00
6701af6425
better readable, tested, and following standard notation
2020-03-01 23:00:06 +01:00
6dfc48f89e
better use names known from numpy
2020-03-01 09:52:46 +01:00
4ab3bfe96d
polishing/simplifying
2020-03-01 09:41:42 +01:00
3713810592
simplified allocation for same shape
2020-02-29 13:53:04 +01:00
bcccf06450
Merge remote-tracking branch 'origin/development' into less-public-variables
2020-02-29 13:18:02 +01:00
1d77af66c0
preparing removal of initializeStructure
2020-02-26 07:23:29 +01:00
839443bc85
better (generic) name where possible
2020-02-26 07:06:25 +01:00
cbcb7dca5d
cleaning
2020-02-26 06:12:45 +01:00
82dee9db0e
matching names
2020-02-25 17:53:15 +01:00
48604292e2
Merge remote-tracking branch 'origin/development' into MiscImprovements
2020-02-25 17:33:39 +01:00
4889e75e52
clearer structure
2020-02-25 17:32:49 +01:00
2c952c3410
these variables can be at leat write protected
2020-02-25 09:50:21 +01:00
7d7eff0d94
crystallite should be responsible of crystallite variables
2020-02-25 09:42:07 +01:00
a2e8e5b13b
Merge branch 'simple-output-handling' into development
2020-02-23 19:38:13 +01:00
49de01787d
variables not used
2020-02-23 16:38:57 +01:00
605e976915
I don't like loops
...
use language features and helper functions for shorter code
2020-02-23 09:45:19 +01:00
7d6c0dc5f4
is only needed during initialization
2020-02-22 11:42:06 +01:00
2cf89b1fdd
bugfix: output dataset was too large in case of Ngrains>1
...
material_phaseAt is defined per constituent/grain/component => no need
to multiply with homogenization_maxNgrains
2020-02-22 11:28:03 +01:00
bedcd0ad8c
sanity check for homogenization
...
number of (constituent) per microstructure need to match Nconstituents
in homogenization.
2020-02-22 11:14:11 +01:00
62898a70a0
use automated LHS allocation
2020-02-21 23:40:29 +01:00
f72b856a18
no reason for critical
...
will always (and only) set to .true.
2020-02-21 23:37:35 +01:00
402c282e68
better names
...
backport form dadf5-usability
2020-02-21 13:27:41 +01:00
6a90796618
bugfix: wrong string for comparison
2020-02-21 09:42:56 +01:00
a2e710c89c
alinged for better readability
2020-02-21 08:45:11 +01:00
c9c78aa90d
do not store invFp and invFi for all points
...
requires to explicitly calculate inverse of Fp and Fi for the tangent
calculation. Hence, classical tradeoff between memory consumption and
runtime.
2020-02-21 08:41:08 +01:00
1a0f4b185f
Merge branch 'development' into simple-output-handling
2020-02-20 22:18:58 +01:00
ab88ffd28e
Merge branch 'MiscImprovements' into development
2020-02-20 22:15:02 +01:00
d108d76a61
was never read
...
probably it was optimized away by the compiler, still confusing
2020-02-20 15:08:32 +01:00
ef4b7437f3
Input arguments of a function to be declared first.
2020-02-20 14:01:26 +01:00
dc7e7e5bcc
less writing, same functionality
2020-02-14 23:21:58 +01:00
420d9bd036
no enums for thermal
...
better readable, less line of code
2020-02-14 22:50:30 +01:00
7311d50df7
final enum removal for plastic laws
2020-02-14 21:41:13 +01:00
a8e2ee0a86
[skip ci] is read only for other modules
2020-02-14 21:31:03 +01:00
b1780e71c8
style unification, no enums for output
2020-02-14 09:23:09 +01:00
8d6c82e704
no need for enums
...
they just complicate the code, any performance gain should be negligible
2020-02-14 09:00:14 +01:00
486385978c
no need for outputID
...
just adds overhead, one string comparison per output and increment is
computationally not an issue
also unified to PEP recommendation of function description
2020-02-14 08:39:29 +01:00
6adb116712
[skip ci] whitespace adjustments
2020-02-14 06:24:17 +01:00
4f7bbb323e
not needed
2020-02-13 18:43:20 +01:00
64e86666c6
also set initial det(Fp)=0
...
Marc element lib test failed otherwise for type 117
2020-02-13 17:10:27 +01:00
0f70a19266
Fp matters, not Fp^-1
...
mathematically absolutely equivalent, but numerically not. Sometikes makes a
huge difference in convergence behavior, even though abs(det(Fp)-1) is
in the order of 1e-15
2020-02-13 14:48:32 +01:00
fc82ec9b1b
tiny deviations from det(Fp) = 1 cause convergence problems
2020-02-13 09:18:49 +01:00
fa903c6f35
not needed anymore
2020-02-12 20:50:09 +01:00
b861ad11c1
tiny differences between orientation conversions result in more
...
iterations
Seen so far only for plasticityDetectChanges test (confirmed for dislotwin and
phenopowerlaw).
The max difference between the entries of the rotation matrix from
orientation0%asMatrix() and eu2om(Eulers)/eu2om(orientation0%asEulers) is
1e-15. This is the ratio of km/atom radius! Still, the number of
iterations is consistently higher.
Results are the same. I believe this is a strange coincidence where one
particular orientation causes problems. The current version recovers almost the 'good' behavior
of math_EulerToR(Eulers)
2020-02-12 20:49:02 +01:00
8770613e9c
better readable
2020-02-12 06:26:22 +01:00
ab475b7c6b
need 'error return'
...
revert from change in 5b72110d
2020-02-12 06:02:37 +01:00
08174a119f
consistent name
2020-02-11 17:50:07 +01:00
5b72110d0a
simplified
2020-02-11 17:47:48 +01:00
Martin Diehl