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
e212f91fac
print statements prevents reading code
...
first re-structure and clean, than re-implement where useful
2020-02-11 17:41:30 +01:00
6463fcdabd
consistent names
2020-02-11 17:36:43 +01:00
c2c84d698f
Merge remote-tracking branch 'origin/development' into MiscImprovements
2020-02-11 17:11:43 +01:00
81ae66860a
Merge remote-tracking branch 'remotes/origin/explicitNonlocal' into development
2020-02-11 10:32:53 +01:00
a306e473ef
use rhoSgl0 (converged situation)
2020-02-11 05:41:10 +01:00
cd76172d74
debugging PETSc
2020-02-08 09:17:44 +01:00
187b3603d3
using new names
2020-02-08 09:08:52 +01:00
8f2e345ab4
polishing
2020-02-08 08:19:06 +01:00
4c4c052e73
slowly getting newer PETSc versions to work
2020-02-08 07:03:18 +01:00
5456ee98f4
still needed (new section was created)
2020-02-08 06:59:37 +01:00
984370d7d1
not needed
2020-02-07 18:34:00 +01:00
e932b386b9
Merge branch 'development' into MiscImprovements
2020-02-07 17:11:01 +01:00
5d4d1dcf9a
all nonlocal parts are fully explicit
...
i.e. they are based on converged (partioned0) states
2020-02-07 12:41:01 +01:00
f854dc27e9
explicit dotState for nonlocal
...
all flux related quantities are calculated based on the converged
quantities
2020-02-07 12:23:22 +01:00
4f4c6c5949
using converged dislocation velocity (from last subinc)
2020-02-07 12:01:54 +01:00
c7e3ac28f6
preparing data handling for explicit forward of flux
2020-02-07 11:44:03 +01:00
1ceba73d31
adopting to PETSc >3.10
...
thanks to Matthew Knepley from the PETSc team
2020-02-07 09:10:08 +01:00
98e5713ce5
Merge branch 'development' into noAbaqus
2020-02-06 18:33:13 +01:00
47109b903b
Merge branch 'plasticity-submodule' into 'development'
...
Plasticity submodule
See merge request damask/DAMASK!120
2020-02-06 10:13:48 +01:00
cab000f4b4
not used
2020-02-04 23:52:10 +01:00
13ce372684
not used
2020-02-04 23:45:34 +01:00
2d74a83dad
cleaning
2020-02-03 23:48:09 +01:00
9e131c0110
rank 0 takes care of statistics file
2020-02-03 23:09:46 +01:00
e9dad64f2b
use central functionality
2020-02-03 23:01:08 +01:00
7bdfd05749
simplified
2020-02-03 22:44:57 +01:00
c6579f8890
[skip ci] unified
2020-02-03 22:41:52 +01:00
1ad79883b4
not needed
2020-02-03 22:33:56 +01:00
0ce0bb2d85
better understandable
2020-02-03 21:39:00 +01:00
54589a9c56
crystallite does not exist any more
2020-02-02 20:37:05 +01:00
588525611b
also report correctly negative seeds
2020-02-01 09:04:02 +01:00
796fd9a774
natural order
2020-01-31 21:43:45 +01:00
042d09a730
names from paper
2020-01-31 21:43:12 +01:00
55e53536f2
fixing indentation
...
always 2 spaces, not 1 for the first level
2020-01-31 21:37:18 +01:00
26496976c8
not used anymore
2020-01-31 21:19:15 +01:00
0d96c728fe
better readable
2020-01-31 07:02:24 +01:00
3791c50468
better readable
2020-01-31 06:55:26 +01:00
f5f397cb70
better readable
2020-01-31 06:52:11 +01:00
6ce4ce523a
Merge branch 'MiscImprovements' of magit1.mpie.de:/damask/DAMASK into MiscImprovements
2020-01-31 00:13:25 +01:00
269d65005b
use nomenclature from the DAMASK paper
2020-01-31 00:07:23 +01:00
0b8ff64884
store mapping MARC/FEM2DAMASK mapping
...
do not calculate the mapping for elements and nodes per call on
the fly, rather store it. Not memory efficient in the case that numbers
are not consequtive (order does not matter, but missing nodes/elements
would waste some 2 integers per missing number). However, this seem to cause
problems anyway when range indicators like '1 to 10' are used.
2020-01-30 23:39:59 +01:00
d54b8714e1
avoid invalid error access
2020-01-29 23:42:50 +01:00
c2cdcb17f7
wrong string
2020-01-29 23:04:15 +01:00
59fe9d06b0
shortening
2020-01-29 22:53:19 +01:00
9690f170e1
4 space indentation
2020-01-29 22:44:42 +01:00
f5bd544b36
[skip ci] was too general
2020-01-29 18:15:49 +01:00
9c138c87f0
not needed
2020-01-29 14:57:12 +01:00
64be6a277d
it's the surface, not the edge
2020-01-29 14:48:15 +01:00
b938f1a98d
polishing
...
* constants in CAPITALS
* more tests
* 'forall' is deprecated in Fortran 2018
2020-01-29 14:01:14 +01:00
348a91d503
Merge branch 'MiscImprovements' of magit1.mpie.de:/damask/DAMASK into MiscImprovements
2020-01-29 13:17:58 +01:00
3f96c12e06
avoid code duplication
2020-01-29 11:09:57 +01:00
49bfdcecab
avoid accessing non-existing chunks
...
note that Fortran does not shortcut logical expressions, hence the new
function
2020-01-29 09:13:55 +01:00
b8263519ca
ignore empty lines
2020-01-29 08:00:28 +01:00
7b0850f929
only read relevant lines
2020-01-29 00:10:05 +01:00
57db134c6d
polishing
2020-01-28 23:44:07 +01:00
5d1f68bf93
Merge branch 'fix-elem-7-57' into noAbaqus
2020-01-27 19:27:53 +01:00
6636f56cab
Merge remote-tracking branch 'origin/development' into fix-elem-7-57
2020-01-27 19:23:35 +01:00
fb5e57aa1a
WIP: implementing static map for Marc->DAMASK (elem/nodes)
2020-01-26 23:12:48 +01:00
d2a3fd3ac8
not needed to parse in nElem
2020-01-26 22:51:06 +01:00
f044b8c42f
explain data layout
2020-01-26 21:58:36 +01:00
0a1bac6787
flush helps to detect errors
2020-01-26 21:50:43 +01:00
f546ffb3be
polishing
2020-01-26 21:22:55 +01:00
79aeea052f
does not exist anymore (is not needed)
2020-01-26 21:07:21 +01:00
f8c5dbea71
typo (MSC.Marc did not compile)
2020-01-26 21:02:32 +01:00
cda1f4acab
more tests
...
failed unitTests report consistently with "internal error"
2020-01-26 20:53:13 +01:00
a4134b4552
doing some internal checks
...
trivial, but better safe then sorry
2020-01-26 20:24:09 +01:00
830b05005f
read file only once
2020-01-26 19:56:30 +01:00
62865e779d
polishing
2020-01-26 18:31:56 +01:00
a6e979ae1f
simplified parsing of strings, floats, and ints
...
invalid characters for interpretation as float and int now raise error,
no warning
requesting invalid chunk now raises error, no warning
2020-01-26 18:23:23 +01:00
0eba4e39cc
trying to make the whole procedure understandable
2020-01-26 14:18:16 +01:00
81fba131f6
variable string length
2020-01-26 13:28:12 +01:00
decf9371ea
avoid issues with unsufficient length of strings
2020-01-26 13:18:29 +01:00
3b8dd17e5b
avoiding hard-coded constants
2020-01-26 12:25:45 +01:00
fe22b84d5c
maximum path length is 4096
2020-01-26 12:19:36 +01:00
9c7f6811a2
use default string length
2020-01-26 12:17:59 +01:00
1be37de993
not used (defaults are given in the respective modules)
2020-01-26 11:46:14 +01:00
24a8d7ed29
256 (pStringLen) might not be sufficient for file operations
2020-01-26 11:40:25 +01:00
9a0d8db23e
[skip ci] replacement is done
2020-01-26 10:53:24 +01:00
ffea69955e
polishing and testing
...
element 11/12 (7/57 for MSC.Marc) have the same geometry type, i.e. both
are a hexahedral with 8 integration points/cells
Type 11 is linear (8 nodes), type 12 quadradic with reduced integration (20 nodes).
The modified definition ensures that the cell nodes 9-20 of element 11
are in the same order as the real nodes 9-20 of element 12. Real nodes
1-8 (corners) and 21-27 needed no modification.
Notes:
* Documentation on https://damask.mpie.de/Documentation/ElementType is now outdated.
* Element defition in MSC.Marc manual volume B (2001 version) is
confusing because element numbering is sometimes clowise and
sometimes counterclockwise. The latter one seems to be correct
2020-01-26 09:24:32 +01:00
Martin Diehl