432609ec14
cleaning
2020-07-03 16:45:11 +02:00
77e7e3d3c4
polishing
2020-06-26 20:12:05 +02:00
853f73400e
tried to access root pointer before initialization
2020-06-19 01:05:44 +02:00
9a03a6d13a
exception for marc
2020-06-18 19:31:08 +02:00
06f6e15123
avoid public variables
2020-06-16 07:05:31 +02:00
0a9902818c
polishing
2020-06-16 06:34:12 +02:00
e5c9380bac
cleaning
2020-06-11 08:52:22 +02:00
579ced6a52
removed global public variables
2020-06-11 08:44:24 +02:00
b353129ba8
cleaning
2020-06-11 08:36:21 +02:00
82326ed812
drop support for ping-pong scheme
2020-06-11 08:22:25 +02:00
f2164a5bd3
simplified
...
openMP is not used here ...
2020-04-27 13:40:22 +02:00
2a37acfe5e
store data where it is needed
2020-03-29 20:04:51 +02:00
7aa47d8f5a
module name follows filename
2020-03-20 07:18:11 +01:00
e53ba801fa
more systematic file structure
2020-03-15 17:04:28 +01:00
705ee908a2
Merge remote-tracking branch 'origin/development' into clean-and-polish-damage
2020-03-10 13:49:11 +01:00
18ccc49d6f
avoid duplicated public/private statements
...
variables should be private
2020-02-29 15:15:41 +01:00
82dee9db0e
matching names
2020-02-25 17:53:15 +01:00
7d7eff0d94
crystallite should be responsible of crystallite variables
2020-02-25 09:42:07 +01:00
26496976c8
not used anymore
2020-01-31 21:19:15 +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
3b8dd17e5b
avoiding hard-coded constants
2020-01-26 12:25:45 +01:00
8a2a9d3861
avoid direct file operations
2020-01-25 13:30:42 +01:00
624ede8177
clear separation between solver and DAMASK
2020-01-25 09:12:09 +01:00
bdae2a40cc
independent of IO
2020-01-25 08:56:39 +01:00
7f66d4e975
avoid fixed string length
...
solved issues with wrong trim and is more robust
2020-01-23 11:21:42 +01:00
246187865e
more flexibility
2020-01-23 08:19:21 +01:00
46cb787934
avoid HDF5 error when creating link twice
2020-01-12 00:55:00 +01:00
ffb112b0d8
Merge branch 'development' into DADF5-improvements
2019-10-30 17:16:54 +01:00
c1cf64bf00
was not used/tested
2019-10-24 12:15:22 +02:00
0b4605361b
plotv only needed for postResults
2019-10-20 19:23:50 +02:00
4999aa4e14
more cleaning
2019-10-13 19:41:55 +02:00
b647245e39
general polishing
2019-10-08 18:52:34 +02:00
04272f88d5
untangling
...
- avoid public variables
- openMP in initialization hardly useful
- structure of init should reflect tasks:
1) reading
2) discretization
3) nonlocal stuff
2019-10-08 09:30:32 +02:00
4256f67919
polishing
2019-06-15 16:21:37 +02:00
c7703d7aaf
preprocessor statements need to start at column 0
2019-06-07 07:45:54 +02:00
2a35a78d93
phase out mesh_elem and theMesh
2019-06-07 07:38:48 +02:00
00189554cd
correct style
2019-06-06 13:22:46 +02:00
c0964dfd88
disable coordinate update for the moment
2019-06-06 13:13:22 +02:00
2ccfc9f6da
simpler to use variables directly
2019-05-18 23:10:40 +02:00
51e19048f7
pInt not needed anymore
2019-05-14 22:52:33 +02:00
4a0584fe25
commercial FEM solvers write results to HDF5
2019-05-05 12:06:55 +02:00
81cfa31b31
[skip ci] with DAMASK ASCII art
2019-03-13 06:16:31 +01:00
fb6a6e9db5
[skip ci] corrected year
2019-03-12 22:56:09 +01:00
383e1befd5
polishing and extending citations
2019-03-09 11:11:40 +01:00
1ba27cf62d
same reporting style, more error checks
2019-03-09 11:11:40 +01:00
19da2b911d
flux subroutine for Abaqus
...
related comments
2019-02-27 09:23:05 +01:00
77d60be127
avoid superfluous reporting
2019-02-16 11:30:56 +01:00
af83427e8c
Merge branch 'development' into 53-separate-mesh-for-different-solvers-3
2019-02-16 10:25:42 +01:00
afdaac47af
avoid disturbing reporting
2019-02-15 22:54:38 +01:00
59dd9b16e1
cleaning
2019-02-03 16:40:15 +01:00
Martin Diehl