f5af352644
whitespace adjustments
2021-07-23 00:09:51 +02:00
d682b477dd
following paper
2021-07-22 23:22:45 +02:00
85fd2e3fad
not needed
2021-07-22 23:15:20 +02:00
3f7043de74
standard name
2021-07-22 23:15:20 +02:00
7e27baacfe
missing conversion
2021-07-22 21:39:05 +02:00
bd9cae11a5
allow multi line scalar list items.
...
If a scalar list item has ',', the parser would consider it as a separator and not a part of the string
For the moment, this scalar item is enclosed with double quotes ""
In the next step, the flow parser should be able to use this quotes as an indicator for strings
2021-07-22 15:51:33 +02:00
a03aa97970
default name
2021-07-22 15:41:09 +02:00
4fab078d18
multinomial tested+simplified
2021-07-22 15:31:30 +02:00
d9aa638ad7
shorter
2021-07-22 15:11:38 +02:00
5ac592eb9e
initialize L_(i/p), L_(i,p)0
2021-07-22 12:31:10 +02:00
69cc0b528b
do calculation for initialization
2021-07-22 11:38:03 +02:00
aa03e59306
same statement, different syntax but silences gfortran runtime warning
...
with automated LHS, compiling in DEBUG mode (tested for mesh solver)
gives:
home/m/DAMASK/src/phase_mechanical.f90:1010:43: runtime error: signed integer overflow:
-9223372036854775808 - 1 cannot be represented in type 'integer(kind=8)'
2021-07-22 11:24:10 +02:00
5b66db8a39
only mechanics at the moment
...
will be extended, but most likely differently
2021-07-22 10:12:43 +02:00
eb834b635d
unify notation with grid
...
consistent style: Symbols, not descriptions.
also removed untested/unused loginc functionality. Once load cases are
written in YAML, we can introduce the scaling as in DAMASK_grid
2021-07-22 08:48:44 +02:00
173a5f8e55
less public/unneeded variables
2021-07-22 07:48:01 +02:00
574cfd7034
Merge remote-tracking branch 'origin/development' into more-flexible-L
2021-07-22 00:20:33 +02:00
de7ef43095
documenting/silencing gfortran
2021-07-21 23:49:24 +02:00
aace5d25a8
initialization needed
2021-07-21 23:19:41 +02:00
58a7921966
no need for temp, pack instead of reshape for 1D array
2021-07-21 22:45:04 +02:00
b817c620a3
let the computer count
2021-07-21 21:25:33 +02:00
23077fd58c
testing coordinates
...
I don't understand why this pattern exists (with w(2) = 3, w(3) = 2),
but it exists
2021-07-21 19:42:53 +02:00
5a04a1d661
let the computer do the counting
2021-07-21 19:41:14 +02:00
c56979e2ad
single source of truth
2021-07-21 18:47:19 +02:00
000007ba59
better test automatically
2021-07-21 18:06:37 +02:00
b1ba64e6af
understanding floating point precision
...
double can use 16 or 17 significant figures
- if the leading number is high (above 5 or so), only 16 figures are
significant.
- a trailing 1 is never significant
2021-07-21 18:04:50 +02:00
76572e4ca9
standard notation
2021-07-21 16:34:33 +02:00
e3e9dfdc60
following paper
2021-07-21 16:29:57 +02:00
8feeda6f05
phase_mechanical_elastic should store data related to elasticity
2021-07-21 16:23:21 +02:00
fc5237fa80
using central values
2021-07-21 15:46:38 +02:00
8259cb3cdc
notation as in paper
2021-07-21 15:03:28 +02:00
b2e94974ca
short names
2021-07-21 14:52:37 +02:00
f25dee4c3a
quad points updated and rounded based on literature values
2021-07-21 14:34:18 +02:00
df1fe39dc2
Merge remote-tracking branch 'origin/development' into write_ipdisplacements
2021-07-21 13:30:12 +02:00
9d349f8a7c
symbolic notation
2021-07-21 06:50:28 +02:00
b5bf1d525e
Merge remote-tracking branch 'origin/development' into more-flexible-L
2021-07-21 06:36:05 +02:00
6f19113072
L, P, F, etc. are second order tensors
2021-07-21 06:19:04 +02:00
b98819a36c
adjusting names
2021-07-20 18:29:21 +02:00
a919ac0aea
Merge branch 'write_ipdisplacements' of git.damask.mpie.de:damask/DAMASK into write_ipdisplacements
2021-07-20 15:35:48 +02:00
86d918367f
Round quadrature points
2021-07-20 15:34:13 +02:00
85735605f8
more flexibility for the L in the load case
...
Note that mixed boundary conditions for L introduce an ambiguity.
Consider:
L = [[1.0, x, x],
[ 0, 0, 0],
[ 0, 0, 0]]
P = [[x, 0, 0],
[x, x, x],
[x, x, x]]
What we need is F^(n+1)=F_dot^(n+1) x Delta_t, where F_dot^(n+1) is
F_dot^(n+1)_ij = L_ik F^n_kj.
So component F_11 has contributions from L_12 and L_13. We first assume
L_12=L_13=0 and then choose F^(n+1)_12 and F^(n+1)_13 to get
P_12=P_13=0. This implicitly gives a solution for L_12 and L_13, which
is however only one out of infinitely many.
2021-07-20 07:10:28 +02:00
03b7532cc5
numpy.MaskedArray behavior
2021-07-19 23:27:10 +02:00
1c1dc9383e
symbolic names
2021-07-19 22:30:20 +02:00
4a2e62fdb2
Merge branch 'development' into 'write_ipdisplacements'
...
# Conflicts:
# src/mesh/mesh_mech_FEM.f90
2021-07-19 17:19:40 +00:00
a654cd4fb1
To avoid fortran double variable truncation for quadrature points
2021-07-19 17:07:43 +02:00
97203ff551
document and keep definitions together
2021-07-18 23:30:30 +02:00
53b7aab29d
use ph,en access pattern
2021-07-18 09:48:49 +02:00
6ad6158bfb
(en)try is the name used in the DADF5 file
2021-07-18 09:44:52 +02:00
57ad308a7f
readable
2021-07-18 09:22:12 +02:00
d068f45aa0
avoid superflouos damage calculations
2021-07-17 15:25:00 +02:00
c109d5a37b
better have different physics separated
2021-07-17 14:06:48 +02:00
f9edeb40a5
descriptive names
2021-07-17 11:50:21 +02:00
e6d25294d3
separating functionality
2021-07-16 23:32:08 +02:00
fc735d6391
substate0 only needed for staggered state-stress integration
2021-07-16 23:19:48 +02:00
777620b800
polishing
2021-07-16 22:41:38 +02:00
594ad2c310
semi-separate handling of damage
2021-07-16 22:22:41 +02:00
2b24224c7e
more meaningful name
2021-07-16 20:52:41 +02:00
ed6b1be352
solver handles terminally ill
2021-07-16 20:43:08 +02:00
2a84aa7ae4
obvious, no need for comment
2021-07-16 20:32:21 +02:00
5f78f1753c
split up thermal
...
only for grid at the moment
2021-07-16 18:03:38 +02:00
3f0eafd640
first step towards separating of mechanics, thermal, and damage
2021-07-16 17:53:11 +02:00
013c4c0a92
common variable names
2021-07-16 10:31:40 +02:00
2f1fa8292b
unify style to majority of occurences
2021-07-16 10:30:45 +02:00
3830492791
Merge remote-tracking branch 'origin/development' into write_ipdisplacements
2021-07-15 17:34:44 +02:00
4d6a9a51ed
correct logic
2021-07-15 17:32:41 +02:00
94843becda
writing ip displacements (algorithm contain bugs)
2021-07-14 19:33:54 +02:00
766db0524f
Merge remote-tracking branch 'origin/Marc-start-material-at-0' into marc2021.2
2021-07-14 18:06:57 +02:00
05b319fbfb
easier to read
2021-07-14 06:33:04 +02:00
2ffa6cac70
Merge remote-tracking branch 'origin/development' into Marc-start-material-at-0
2021-07-14 06:15:46 +02:00
ce3b4d2a2a
Merge branch 'development' into YAML-fixes
2021-07-13 20:27:21 +02:00
45abca90c5
stricter
...
example of invalid YAML--> mechanical:{type: pass}
2021-07-12 22:17:02 +02:00
d2560ebb39
function should return either 'true' or 'false' and not bear the responsibility to throw errors
...
We were forcing every colon to indicate either key or key: value
2021-07-12 21:42:51 +02:00
df9a94422f
0-based indexing in MSC.Marc
...
inline with Python library and grid, still need to decide on mesh (neper
is 1-based)
2021-07-10 09:49:29 +02:00
136a4b1377
PETSc defines are rather complicated
...
now mpi_f08 can be used on newer PETSc installations if old MPI modules
are not exposed
2021-07-09 18:48:25 +02:00
637f78bd52
old name (for PETSc < 3.15)
2021-07-09 14:50:29 +02:00
3870a70a4e
HDF5 seems to use MPI (F90 style)
2021-07-09 12:37:39 +02:00
8e75e87ad9
Merge branch 'MPI_F08' into polishing-for-beta
2021-07-09 11:32:32 +02:00
c3e94cf1fe
Marc2021.2 is out!
2021-07-09 08:59:04 +02:00
f54bd8f3a9
correct capitalization
2021-07-08 17:56:49 +02:00
139f2c177a
use MPI_f08 if possible
...
most PETSc installations provide outdated MPI (f90 version)
MPI_COMM_WORLD is now of derived type (Fortran 08 style)
PETSC_COMM_WORLD is the plain integer (f90 style) alias.
Note that HDF5 is assumed to have f90 interfaces
2021-07-08 16:27:37 +02:00
4c3ff4bef4
consistent capitalization
2021-07-08 15:05:01 +02:00
58bc6e2ba6
avoid chained inclusions
2021-07-08 14:27:04 +02:00
69415d2e05
not needed
2021-07-08 12:30:00 +02:00
3c6c5d77e8
following paper
2021-07-06 22:58:18 +02:00
a13e02da44
easier to follow
2021-07-06 22:33:12 +02:00
cd9d704aae
bug fixes:
...
invalid material.yaml, detect such errors in future
2021-07-05 11:30:52 +02:00
f0a75d8d62
consistent capitalization
...
Capitals for pre processor macros to avoid clashes
2021-07-04 17:43:19 +02:00
6dc70fa4e7
not used anywhere
...
was only required for ductile damage
2021-07-04 08:51:53 +02:00
7daef03e65
new multiphyics notation
2021-07-03 22:50:14 +02:00
8acecc1306
preparing standard multiphysics notation
2021-07-03 22:41:34 +02:00
f69f61dcb7
avoid duplication
2021-07-03 22:30:06 +02:00
a0ffbc5f17
little polishing
...
- same names as for grid
- 'local' naming misleading here (probably for x_local etc also not a
good choice)
- following names in PETSc notation (https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/DMPLEX/DMPlexGetPointLocal.html )
- using allocation with bounds to simplify access
- NOTE: The nodal coordinates are not what damask.Result expects except
for simple, 1 IP elements!
2021-07-02 23:49:06 +02:00
1516ded71b
Merge remote-tracking branch 'origin/development' into write_displacements
2021-07-02 23:07:51 +02:00
7745640393
consistently use prefix as modifier
2021-06-28 23:41:50 +02:00
f2a359bea1
relaxing tolerances
...
allowed for simplified cases (no temperature dependency/friction)
2021-06-28 23:28:41 +02:00
5973ef5b13
Merge remote-tracking branch 'origin/nonlocal-examples' into preparing-alpha4
2021-06-28 23:22:16 +02:00
6651656903
isoductile is not working
2021-06-28 23:13:56 +02:00
b1f4c06f9c
takeover from Christophs thesis
2021-06-26 13:25:13 +02:00
b322ed3e03
feauture to write nodal displacements to hdf5 file added
2021-06-25 20:46:21 +02:00
ab0e65c6bc
systematic names and sensible defaults
2021-06-25 15:12:54 +02:00
06e76c1a81
consistent default absolute tolerances
...
better use conservative values, users can easily relax if needed
2021-06-25 10:13:03 +02:00
a9f5dcfbf1
avoid allocate based on random value in sum_N_sl
2021-06-24 23:35:14 +02:00
106fec92d7
C is the common symbol
2021-06-24 19:14:19 +02:00
8f5a370388
bugfix: update compatibility for nonlocal
...
intent(out) resulted in setting nonlocal = .false.
now using plasticState%nonlocal consistently
2021-06-24 18:59:52 +02:00
f42157c076
consistent names
2021-06-24 16:31:07 +02:00
f834a1534e
simplified
2021-06-24 16:07:54 +02:00
12ca7428cf
cleaning
2021-06-24 15:25:43 +02:00
ae9a48c124
polishing
2021-06-24 15:23:24 +02:00
b4265149c8
simplified
2021-06-24 15:08:31 +02:00
95c9434a21
bugfix: enable local simulations
2021-06-24 15:01:32 +02:00
8c06e7a4ff
generic and extendable multiphysics notation
2021-06-24 14:49:09 +02:00
c49ba5419b
sign-transfer done right
2021-06-21 23:26:17 +02:00
4b82cb4c14
extra parameter needed
...
Hardening parameters determine rate of hardening in phenopowerlaw.
This flexibility is also needed in J2.
2021-06-21 23:22:51 +02:00
27431bd60c
avoid division by M gives better agreement with phenopowerlaw
2021-06-21 23:11:09 +02:00
ea4867770f
avoid error due to limited floating point accurary
2021-06-21 16:15:40 +02:00
38e4802867
3.15.1 works (3.15.0 has a bug)
2021-06-21 06:53:17 +02:00
0a22916aba
not a double subscript
2021-06-19 15:13:27 +02:00
8bba021fe1
Merge remote-tracking branch 'origin/development' into mesh_test
2021-06-18 19:23:20 +02:00
36bf68b336
Out of plane coordinates for 2D elements are updated with dummy values
2021-06-17 20:26:37 +02:00
b9d4217d86
permutationStar111 for 4th order integration is updataed
2021-06-16 14:58:26 +02:00
1bfbd30ae2
polishing
2021-06-15 19:53:05 +02:00
218e6a79a8
VTK image data is the appropriate type, not VTK rectilinear grid
...
FFTs require constant spacing in all three directions, this is
guaranteed by the vtkImageData but not by vtkRectilinearGrid
2021-06-15 19:02:26 +02:00
e10701b32a
easier to understand
2021-06-14 15:21:10 +02:00
5f01b076d2
This change makes the test work for GNU too
...
Probably something was uninitialized and GNU was accessing unallocated memory
2021-06-14 14:58:14 +02:00
c64f9eb805
hardcoding '3' is an issue for 2d simulations
2021-06-11 20:42:31 +02:00
3705f1d3a2
F,P, ... in loadcase are 2nd order tensors
2021-06-03 08:21:16 +02:00
6cd0d79c61
old merge not reflected
2021-06-02 14:08:12 +02:00
39c2506b8d
Merge branch 'Fortran-cleaning' into 'development'
...
Separating functionality
See merge request damask/DAMASK!396
2021-06-02 09:24:47 +00:00
fada9a7f6c
more meaningful order
2021-06-01 17:05:13 +02:00
5d0fc4fca3
more meaningful order
...
and intent(out) variables for read are at the front
2021-06-01 16:46:24 +02:00
569b1fc563
not needed (duplicated code)
2021-06-01 11:09:02 +02:00
6f9e521cdb
Merge branch 'HDFgeometryupdate' into 'development'
...
HDF geometry update
See merge request damask/DAMASK!395
2021-06-01 08:01:53 +00:00
431416b5ba
Separating functionality
...
lattice should become a module with static data and functions
2021-06-01 07:56:55 +02:00
91015fd07c
write out undeformed configuration
2021-05-31 19:41:22 +02:00
650fbd7509
Initial nodal and ip coordinates added to the HDF5 output file
2021-05-31 15:01:42 +02:00
718880f177
Initial nodal and ip coordinates added to the HDF5 output file
2021-05-31 14:09:11 +02:00
d1a6607782
Merge branch 'load2Dtensor' into 'development'
...
support for 2D tensor in load case
See merge request damask/DAMASK!391
2021-05-29 13:21:47 +00:00
77a0d5999b
not needed
2021-05-28 19:24:38 +02:00
4669c289c7
Merge remote-tracking branch 'origin/development' into Fortran-cleaning
2021-05-28 15:00:06 +02:00
0240bec5b3
consistent reporting
2021-05-27 08:25:48 +02:00
bdb4029fb5
tI symmetry of 2nd order tensor is equivalent to hP
2021-05-26 22:49:53 +02:00
16128c257a
Merge branch 'development' into fix-thermalexpansion
2021-05-26 22:49:39 +02:00
95f7f3c6ed
Merge remote-tracking branch 'origin/development' into simplify-cmake
2021-05-26 19:11:20 +02:00
adb1e51e24
support for 2D tensor in load case
...
currently optional, but should become mandatory after a transition
period
2021-05-26 08:04:14 +02:00
019159d328
WIP
2021-05-26 06:31:11 +02:00
24e862105c
ensuring correct lattice symmetries
2021-05-25 06:05:51 +02:00
299c47fd6f
prepare for varying C66
...
- check structure centrally
- pure function with guaranteed return/no stop
2021-05-24 20:33:50 +02:00
f525999f52
updated tests
2021-05-24 20:12:34 +02:00
f44edb31fc
polishing
2021-05-24 17:20:33 +02:00
fe281f4592
only Hooke as model
...
and this model should take care of the elastic constants, not lattice
2021-05-24 17:19:38 +02:00
0d0bc188eb
potentially less error prone (and easier to read)
2021-05-24 17:17:27 +02:00
Martin Diehl