223031012
/
DAMASK_EICMD
mirror of https://github.com/achalhp/DAMASK_EICMD.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
DAMASK_EICMD/code/homogenization.f90

770 lines
39 KiB
Fortran
Raw Normal View History

added version information to all files do NOT edit text like this: $Id: constitutive_phenopowerlaw.f90 406 2009-08-31 14:13:10Z MPIE\f.roters $
2009-08-31 20:39:15 +05:30
!* $Id$
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
!***************************************
!* Module: HOMOGENIZATION *
!***************************************
!* contains: *
!* - _init *
!* - materialpoint_stressAndItsTangent *
!* - _partitionDeformation *
!* - _updateState *
!* - _averageStressAndItsTangent *
!* - _postResults *
!***************************************
MODULE homogenization
!*** Include other modules ***
use prec, only: pInt,pReal,p_vec
implicit none
! ****************************************************************
! *** General variables for the homogenization at a ***
! *** material point ***
! ****************************************************************
Tstar_v is now restored at different stages of cutbacking; we need this because preguess of state relies on consistent Tstar_v
2009-06-16 14:33:30 +05:30
type(p_vec), dimension(:,:), allocatable :: homogenization_state0, & ! pointer array to homogenization state at start of FE increment
homogenization_subState0, & ! pointer array to homogenization state at start of homogenization increment
homogenization_state ! pointer array to current homogenization state (end of converged time step)
integer(pInt), dimension(:,:), allocatable :: homogenization_sizeState, & ! size of state array per grain
homogenization_sizePostResults ! size of postResults array per material point
real(pReal), dimension(:,:,:,:,:,:), allocatable :: materialpoint_dPdF ! tangent of first P--K stress at IP
real(pReal), dimension(:,:,:,:), allocatable :: materialpoint_F0, & ! def grad of IP at start of FE increment
materialpoint_F, & ! def grad of IP to be reached at end of FE increment
materialpoint_subF0, & ! def grad of IP at beginning of homogenization increment
materialpoint_subF, & ! def grad of IP to be reached at end of homog inc
materialpoint_P ! first P--K stress of IP
real(pReal), dimension(:,:), allocatable :: materialpoint_Temperature, & ! temperature at IP
materialpoint_subFrac, &
materialpoint_subStep, &
materialpoint_subdt
real(pReal), dimension(:,:,:), allocatable :: materialpoint_results ! results array of material point
logical, dimension(:,:), allocatable :: materialpoint_requested, &
materialpoint_converged
logical, dimension(:,:,:), allocatable :: materialpoint_doneAndHappy
integer(pInt) homogenization_maxSizeState, &
# no need for materialpoint_results in hypela2 # homogenization updated to be compatible with abaqus interface
2009-10-12 22:31:42 +05:30
homogenization_maxSizePostResults, &
materialpoint_sizeResults
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
CONTAINS
!**************************************
!* Module initialization *
!**************************************
Major Update: all modules are now correctly submitted
2009-07-01 16:25:31 +05:30
subroutine homogenization_init(Temperature)
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
use prec, only: pReal,pInt
use math, only: math_I3
debugging output is now controlled by the "verbosity" parameter in the debug.config ranging from 0 (=almost no output) to 8 (=very detailed output) 0 : only version infos and all from "hypela2"/"umat" 1 : basic outputs from "CPFEM.f90", basic output from initialization routines, debug_info 2 : extensive outputs from "CPFEM.f90", extensive output from initialization routines 3 : basic outputs from "homogenization.f90" 4 : extensive outputs from "homogenization.f90" 5 : basic outputs from "crystallite.f90" 6 : extensive outputs from "crystallite.f90" 7 : basic outputs from the constitutive files 8 : extensive outputs from the constitutive files If verbosity is equal to zero, all counters in debug are not set during calculation (e.g. debug_StressLoopDistribution or debug_cumDotStateTicks). This might speed up parallel calculation, because all these need critical statements which extremely slow down parallel computation.
2011-03-21 16:01:17 +05:30
use debug, only: debug_verbosity
now with functionality to output a "JOB.outputHomogenization". This contains size descriptions of all requested output variables to be parsed by a further script to generate meaningful names for user defined vars... (watch out!)
2010-02-19 23:33:16 +05:30
use IO, only: IO_error, IO_open_file, IO_open_jobFile
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
use mesh, only: mesh_maxNips,mesh_NcpElems,mesh_element,FE_Nips
use material
use constitutive, only: constitutive_maxSizePostResults
reworked crystallite part to allow for flexible user output --> new "crystallite" part in config file --> new "crystallite" option for microstructures --> new output file "...job.outputCrystallite" to be used in conjunction with marc_addUserOutput for meaningful naming of User Defined Vars.
2010-02-25 23:09:11 +05:30
use crystallite, only: crystallite_maxSizePostResults
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
use homogenization_isostrain
openmp parallelization working again (at least for j2 and nonlocal constitutive model). In order to keep it like that, please follow these simple rules: DON'T use implicit array subscripts: example: real, dimension(3,3) :: A,B A(:,2) = B(:,1) <--- DON'T USE A(1:3,2) = B(1:3,1) <--- BETTER USE In many cases the use of explicit array subscripts is inevitable for parallelization. Additionally, it is an easy means to prevent memory leaks. Enclose all write statements with the following: !$OMP CRITICAL (write2out) <your write statement> !$OMP END CRITICAL (write2out) Whenever you change something in the code and are not sure if it affects parallelization and leads to nonconforming behavior, please ask me and/or Franz to check this.
2011-03-17 16:16:17 +05:30
use homogenization_RGC
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
quite some changes: # non-greedy memory allocation # generation of outputConstitutive to allow for script-based T16 extraction # exchange of phenomenological by more general phenopowerlaw # lattice is based on slip and twin families which can be treated as individual entities (switched on/off, separate hardening, etc.) # nicer debugging output # changed some error/warning codes # plus potentially some minor additional brushes here and there
2009-07-22 21:37:19 +05:30
real(pReal) Temperature
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
integer(pInt), parameter :: fileunit = 200
now with functionality to output a "JOB.outputHomogenization". This contains size descriptions of all requested output variables to be parsed by a further script to generate meaningful names for user defined vars... (watch out!)
2010-02-19 23:33:16 +05:30
integer(pInt) e,i,g,p,myInstance,j
integer(pInt), dimension(:,:), pointer :: thisSize
character(len=64), dimension(:,:), pointer :: thisOutput
logical knownHomogenization
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
if(.not. IO_open_file(fileunit,material_configFile)) call IO_error (100) ! corrupt config file
call homogenization_isostrain_init(fileunit) ! parse all homogenizations of this type
openmp parallelization working again (at least for j2 and nonlocal constitutive model). In order to keep it like that, please follow these simple rules: DON'T use implicit array subscripts: example: real, dimension(3,3) :: A,B A(:,2) = B(:,1) <--- DON'T USE A(1:3,2) = B(1:3,1) <--- BETTER USE In many cases the use of explicit array subscripts is inevitable for parallelization. Additionally, it is an easy means to prevent memory leaks. Enclose all write statements with the following: !$OMP CRITICAL (write2out) <your write statement> !$OMP END CRITICAL (write2out) Whenever you change something in the code and are not sure if it affects parallelization and leads to nonconforming behavior, please ask me and/or Franz to check this.
2011-03-17 16:16:17 +05:30
call homogenization_RGC_init(fileunit)
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
close(fileunit)
now with functionality to output a "JOB.outputHomogenization". This contains size descriptions of all requested output variables to be parsed by a further script to generate meaningful names for user defined vars... (watch out!)
2010-02-19 23:33:16 +05:30
! write description file for homogenization output
if(.not. IO_open_jobFile(fileunit,'outputHomogenization')) call IO_error (50) ! problems in writing file
do p = 1,material_Nhomogenization
i = homogenization_typeInstance(p) ! which instance of this homogenization type
knownHomogenization = .true. ! assume valid
select case(homogenization_type(p)) ! split per homogenization type
case (homogenization_isostrain_label)
thisOutput => homogenization_isostrain_output
thisSize => homogenization_isostrain_sizePostResult
case (homogenization_RGC_label)
thisOutput => homogenization_RGC_output
thisSize => homogenization_RGC_sizePostResult
case default
knownHomogenization = .false.
end select
write(fileunit,*)
write(fileunit,'(a)') '['//trim(homogenization_name(p))//']'
write(fileunit,*)
if (knownHomogenization) then
reworked crystallite part to allow for flexible user output --> new "crystallite" part in config file --> new "crystallite" option for microstructures --> new output file "...job.outputCrystallite" to be used in conjunction with marc_addUserOutput for meaningful naming of User Defined Vars.
2010-02-25 23:09:11 +05:30
write(fileunit,'(a)') '(type)'//char(9)//trim(homogenization_type(p))
write(fileunit,'(a,i)') '(ngrains)'//char(9),homogenization_Ngrains(p)
now with functionality to output a "JOB.outputHomogenization". This contains size descriptions of all requested output variables to be parsed by a further script to generate meaningful names for user defined vars... (watch out!)
2010-02-19 23:33:16 +05:30
do e = 1,homogenization_Noutput(p)
write(fileunit,'(a,i4)') trim(thisOutput(e,i))//char(9),thisSize(e,i)
enddo
endif
enddo
close(fileunit)
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
allocate(homogenization_state0(mesh_maxNips,mesh_NcpElems))
allocate(homogenization_subState0(mesh_maxNips,mesh_NcpElems))
allocate(homogenization_state(mesh_maxNips,mesh_NcpElems))
allocate(homogenization_sizeState(mesh_maxNips,mesh_NcpElems)); homogenization_sizeState = 0_pInt
allocate(homogenization_sizePostResults(mesh_maxNips,mesh_NcpElems)); homogenization_sizePostResults = 0_pInt
allocate(materialpoint_dPdF(3,3,3,3,mesh_maxNips,mesh_NcpElems)); materialpoint_dPdF = 0.0_pReal
allocate(materialpoint_F0(3,3,mesh_maxNips,mesh_NcpElems));
allocate(materialpoint_F(3,3,mesh_maxNips,mesh_NcpElems)); materialpoint_F = 0.0_pReal
allocate(materialpoint_subF0(3,3,mesh_maxNips,mesh_NcpElems)); materialpoint_subF0 = 0.0_pReal
allocate(materialpoint_subF(3,3,mesh_maxNips,mesh_NcpElems)); materialpoint_subF = 0.0_pReal
allocate(materialpoint_P(3,3,mesh_maxNips,mesh_NcpElems)); materialpoint_P = 0.0_pReal
Major Update: all modules are now correctly submitted
2009-07-01 16:25:31 +05:30
allocate(materialpoint_Temperature(mesh_maxNips,mesh_NcpElems)); materialpoint_Temperature = Temperature
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
allocate(materialpoint_subFrac(mesh_maxNips,mesh_NcpElems)); materialpoint_subFrac = 0.0_pReal
allocate(materialpoint_subStep(mesh_maxNips,mesh_NcpElems)); materialpoint_subStep = 0.0_pReal
allocate(materialpoint_subdt(mesh_maxNips,mesh_NcpElems)); materialpoint_subdt = 0.0_pReal
allocate(materialpoint_requested(mesh_maxNips,mesh_NcpElems)); materialpoint_requested = .false.
allocate(materialpoint_converged(mesh_maxNips,mesh_NcpElems)); materialpoint_converged = .true.
allocate(materialpoint_doneAndHappy(2,mesh_maxNips,mesh_NcpElems)); materialpoint_doneAndHappy = .true.
forall (i = 1:mesh_maxNips,e = 1:mesh_NcpElems)
openmp parallelization working again (at least for j2 and nonlocal constitutive model). In order to keep it like that, please follow these simple rules: DON'T use implicit array subscripts: example: real, dimension(3,3) :: A,B A(:,2) = B(:,1) <--- DON'T USE A(1:3,2) = B(1:3,1) <--- BETTER USE In many cases the use of explicit array subscripts is inevitable for parallelization. Additionally, it is an easy means to prevent memory leaks. Enclose all write statements with the following: !$OMP CRITICAL (write2out) <your write statement> !$OMP END CRITICAL (write2out) Whenever you change something in the code and are not sure if it affects parallelization and leads to nonconforming behavior, please ask me and/or Franz to check this.
2011-03-17 16:16:17 +05:30
materialpoint_F0(1:3,1:3,i,e) = math_I3
materialpoint_F(1:3,1:3,i,e) = math_I3
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
end forall
do e = 1,mesh_NcpElems ! loop over elements
myInstance = homogenization_typeInstance(mesh_element(3,e))
do i = 1,FE_Nips(mesh_element(2,e)) ! loop over IPs
select case(homogenization_type(mesh_element(3,e)))
List of changes/modifications: * IO.f90 :: Adding error messages for RGC homogenization * crystallite.f90 :: Modifying convergent criteria in crystalline_updateState and crystalline_updateTemperature * material.f90 :: Adding IO_lc in homogenization_type(Name) * debug.f90 :: Adding debbugging statement and counter for material point loop * homogenization.f90 :: Adding homogenization_RGC blocks * homogenization_isostrain.f90 :: Modifying argument of homogenization_isostrain_stateInit * mpie_cpfem_marc.f90 :: Adding homogenization_RGC include * numerics.f90 :: Adding numerical parameters for RGC scheme * math.f90 :: Changing function name: math_permut to math_civita
2009-07-31 17:32:20 +05:30
!* isostrain
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
case (homogenization_isostrain_label)
if (homogenization_isostrain_sizeState(myInstance) > 0_pInt) then
allocate(homogenization_state0(i,e)%p(homogenization_isostrain_sizeState(myInstance)))
allocate(homogenization_subState0(i,e)%p(homogenization_isostrain_sizeState(myInstance)))
allocate(homogenization_state(i,e)%p(homogenization_isostrain_sizeState(myInstance)))
homogenization_state0(i,e)%p = homogenization_isostrain_stateInit(myInstance)
homogenization_sizeState(i,e) = homogenization_isostrain_sizeState(myInstance)
endif
homogenization_sizePostResults(i,e) = homogenization_isostrain_sizePostResults(myInstance)
openmp parallelization working again (at least for j2 and nonlocal constitutive model). In order to keep it like that, please follow these simple rules: DON'T use implicit array subscripts: example: real, dimension(3,3) :: A,B A(:,2) = B(:,1) <--- DON'T USE A(1:3,2) = B(1:3,1) <--- BETTER USE In many cases the use of explicit array subscripts is inevitable for parallelization. Additionally, it is an easy means to prevent memory leaks. Enclose all write statements with the following: !$OMP CRITICAL (write2out) <your write statement> !$OMP END CRITICAL (write2out) Whenever you change something in the code and are not sure if it affects parallelization and leads to nonconforming behavior, please ask me and/or Franz to check this.
2011-03-17 16:16:17 +05:30
!* RGC homogenization
List of changes/modifications: * IO.f90 :: Adding error messages for RGC homogenization * crystallite.f90 :: Modifying convergent criteria in crystalline_updateState and crystalline_updateTemperature * material.f90 :: Adding IO_lc in homogenization_type(Name) * debug.f90 :: Adding debbugging statement and counter for material point loop * homogenization.f90 :: Adding homogenization_RGC blocks * homogenization_isostrain.f90 :: Modifying argument of homogenization_isostrain_stateInit * mpie_cpfem_marc.f90 :: Adding homogenization_RGC include * numerics.f90 :: Adding numerical parameters for RGC scheme * math.f90 :: Changing function name: math_permut to math_civita
2009-07-31 17:32:20 +05:30
case (homogenization_RGC_label)
if (homogenization_RGC_sizeState(myInstance) > 0_pInt) then
allocate(homogenization_state0(i,e)%p(homogenization_RGC_sizeState(myInstance)))
allocate(homogenization_subState0(i,e)%p(homogenization_RGC_sizeState(myInstance)))
allocate(homogenization_state(i,e)%p(homogenization_RGC_sizeState(myInstance)))
homogenization_state0(i,e)%p = homogenization_RGC_stateInit(myInstance)
homogenization_sizeState(i,e) = homogenization_RGC_sizeState(myInstance)
endif
homogenization_sizePostResults(i,e) = homogenization_RGC_sizePostResults(myInstance)
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
case default
Taylor homogenization is now called isostrain, changed material.config accordingly. corrected error message in case of unknown homogenization
2009-06-08 18:58:00 +05:30
call IO_error(201,ext_msg=homogenization_type(mesh_element(3,e))) ! unknown type 201 is homogenization!
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
end select
enddo
enddo
homogenization_maxSizeState = maxval(homogenization_sizeState)
homogenization_maxSizePostResults = maxval(homogenization_sizePostResults)
# no need for materialpoint_results in hypela2 # homogenization updated to be compatible with abaqus interface
2009-10-12 22:31:42 +05:30
materialpoint_sizeResults = 1+ 1+homogenization_maxSizePostResults + & ! grain count, homogSize, homogResult
reworked crystallite part to allow for flexible user output --> new "crystallite" part in config file --> new "crystallite" option for microstructures --> new output file "...job.outputCrystallite" to be used in conjunction with marc_addUserOutput for meaningful naming of User Defined Vars.
2010-02-25 23:09:11 +05:30
homogenization_maxNgrains*(1+crystallite_maxSizePostResults+ & ! results count, cryst results
1+constitutive_maxSizePostResults) ! results count, constitutive results
allocate(materialpoint_results(materialpoint_sizeResults, mesh_maxNips,mesh_NcpElems))
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
! *** Output to MARC output file ***
!$OMP CRITICAL (write2out)
write(6,*)
write(6,*) '<<<+- homogenization init -+>>>'
added version information to all files do NOT edit text like this: $Id: constitutive_phenopowerlaw.f90 406 2009-08-31 14:13:10Z MPIE\f.roters $
2009-08-31 20:39:15 +05:30
write(6,*) '$Id$'
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
write(6,*)
debugging output is now controlled by the "verbosity" parameter in the debug.config ranging from 0 (=almost no output) to 8 (=very detailed output) 0 : only version infos and all from "hypela2"/"umat" 1 : basic outputs from "CPFEM.f90", basic output from initialization routines, debug_info 2 : extensive outputs from "CPFEM.f90", extensive output from initialization routines 3 : basic outputs from "homogenization.f90" 4 : extensive outputs from "homogenization.f90" 5 : basic outputs from "crystallite.f90" 6 : extensive outputs from "crystallite.f90" 7 : basic outputs from the constitutive files 8 : extensive outputs from the constitutive files If verbosity is equal to zero, all counters in debug are not set during calculation (e.g. debug_StressLoopDistribution or debug_cumDotStateTicks). This might speed up parallel calculation, because all these need critical statements which extremely slow down parallel computation.
2011-03-21 16:01:17 +05:30
if (debug_verbosity > 0) then
write(6,'(a32,x,7(i5,x))') 'homogenization_state0: ', shape(homogenization_state0)
write(6,'(a32,x,7(i5,x))') 'homogenization_subState0: ', shape(homogenization_subState0)
write(6,'(a32,x,7(i5,x))') 'homogenization_state: ', shape(homogenization_state)
write(6,'(a32,x,7(i5,x))') 'homogenization_sizeState: ', shape(homogenization_sizeState)
write(6,'(a32,x,7(i5,x))') 'homogenization_sizePostResults: ', shape(homogenization_sizePostResults)
write(6,*)
write(6,'(a32,x,7(i5,x))') 'materialpoint_dPdF: ', shape(materialpoint_dPdF)
write(6,'(a32,x,7(i5,x))') 'materialpoint_F0: ', shape(materialpoint_F0)
write(6,'(a32,x,7(i5,x))') 'materialpoint_F: ', shape(materialpoint_F)
write(6,'(a32,x,7(i5,x))') 'materialpoint_subF0: ', shape(materialpoint_subF0)
write(6,'(a32,x,7(i5,x))') 'materialpoint_subF: ', shape(materialpoint_subF)
write(6,'(a32,x,7(i5,x))') 'materialpoint_P: ', shape(materialpoint_P)
write(6,'(a32,x,7(i5,x))') 'materialpoint_Temperature: ', shape(materialpoint_Temperature)
write(6,'(a32,x,7(i5,x))') 'materialpoint_subFrac: ', shape(materialpoint_subFrac)
write(6,'(a32,x,7(i5,x))') 'materialpoint_subStep: ', shape(materialpoint_subStep)
write(6,'(a32,x,7(i5,x))') 'materialpoint_subdt: ', shape(materialpoint_subdt)
write(6,'(a32,x,7(i5,x))') 'materialpoint_requested: ', shape(materialpoint_requested)
write(6,'(a32,x,7(i5,x))') 'materialpoint_converged: ', shape(materialpoint_converged)
write(6,'(a32,x,7(i5,x))') 'materialpoint_doneAndHappy: ', shape(materialpoint_doneAndHappy)
write(6,*)
write(6,'(a32,x,7(i5,x))') 'materialpoint_results: ', shape(materialpoint_results)
write(6,*)
write(6,'(a32,x,7(i5,x))') 'maxSizeState: ', homogenization_maxSizeState
write(6,'(a32,x,7(i5,x))') 'maxSizePostResults: ', homogenization_maxSizePostResults
endif
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
call flush(6)
!$OMP END CRITICAL (write2out)
return
added a new module called numerics.f90 which reads in all numerical "parameters" from the file numerics.config (also being added). From now on this file has to be located in the working directory of the FEM-model and has to contain all necessary parameters.
2009-06-15 18:41:21 +05:30
endsubroutine
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
!********************************************************************
!* parallelized calculation of
!* stress and corresponding tangent
!* at material points
!********************************************************************
subroutine materialpoint_stressAndItsTangent(&
updateJaco,& ! flag to initiate Jacobian updating
dt & ! time increment
)
added a new module called numerics.f90 which reads in all numerical "parameters" from the file numerics.config (also being added). From now on this file has to be located in the working directory of the FEM-model and has to contain all necessary parameters.
2009-06-15 18:41:21 +05:30
use prec, only: pInt, &
pReal
minimum substepping size in homogenization and crystallite is now controlled by two independent parameters subStepMinHomog and subStepMinCryst respectively. deleted flush statements where they are not needed, since they seriously slow down computation.
2009-10-26 22:13:43 +05:30
use numerics, only: subStepMinHomog, &
introduced a flexibility in cut-backing scheme in homogenization.f90 and in crystallite.f90: (1) subStepSizeHomog and subStepSizeCryst := size of substep when cut-back is applied (initially was hard-coded). (2) stepIncreaseHomog and stepIncreaseCryst := step increase when calculation for substep converge (was also hardcoded). introduced a possibility to choose different finite difference scheme, i.e., forward-, backward- and central-difference, for computing grain numerical tangent. note that central-difference scheme will slow down the computation significantly. please use it only if necessary. parameters to set these new features have been included in numerics.f90 and numerics.config, whereas corresponding error messages have been introduced in the IO.f90
2009-11-10 19:06:27 +05:30
subStepSizeHomog, &
stepIncreaseHomog, &
now with first draft of nonlocal constitutive law debugging memory leak closed debugging counters corrected center of gravity stored in mesh state updated is now split into a collecting loop and an execution updateState and updateTemperature fill sequentially separate logicals and evaluate afterwards to converged added 3x3 transposition function, norm for 3x1 matrix and 33x3 matrix multiplication in math non-converged crystallite triggers materialpoint cutback (used to respond elastically) non-converged materialpoint raises terminal illness which in turn renders whole FE increment useless by means of odd stress/stiffness and thus waits for FE cutback
2009-08-11 22:01:57 +05:30
nHomog, &
nMPstate
openmp parallelization working again (at least for j2 and nonlocal constitutive model). In order to keep it like that, please follow these simple rules: DON'T use implicit array subscripts: example: real, dimension(3,3) :: A,B A(:,2) = B(:,1) <--- DON'T USE A(1:3,2) = B(1:3,1) <--- BETTER USE In many cases the use of explicit array subscripts is inevitable for parallelization. Additionally, it is an easy means to prevent memory leaks. Enclose all write statements with the following: !$OMP CRITICAL (write2out) <your write statement> !$OMP END CRITICAL (write2out) Whenever you change something in the code and are not sure if it affects parallelization and leads to nonconforming behavior, please ask me and/or Franz to check this.
2011-03-17 16:16:17 +05:30
use math, only: math_det3x3, &
math_transpose3x3
added a new module called numerics.f90 which reads in all numerical "parameters" from the file numerics.config (also being added). From now on this file has to be located in the working directory of the FEM-model and has to contain all necessary parameters.
2009-06-15 18:41:21 +05:30
use FEsolving, only: FEsolving_execElem, &
now with first draft of nonlocal constitutive law debugging memory leak closed debugging counters corrected center of gravity stored in mesh state updated is now split into a collecting loop and an execution updateState and updateTemperature fill sequentially separate logicals and evaluate afterwards to converged added 3x3 transposition function, norm for 3x1 matrix and 33x3 matrix multiplication in math non-converged crystallite triggers materialpoint cutback (used to respond elastically) non-converged materialpoint raises terminal illness which in turn renders whole FE increment useless by means of odd stress/stiffness and thus waits for FE cutback
2009-08-11 22:01:57 +05:30
FEsolving_execIP, &
terminallyIll
debugging output is now controlled by the "verbosity" parameter in the debug.config ranging from 0 (=almost no output) to 8 (=very detailed output) 0 : only version infos and all from "hypela2"/"umat" 1 : basic outputs from "CPFEM.f90", basic output from initialization routines, debug_info 2 : extensive outputs from "CPFEM.f90", extensive output from initialization routines 3 : basic outputs from "homogenization.f90" 4 : extensive outputs from "homogenization.f90" 5 : basic outputs from "crystallite.f90" 6 : extensive outputs from "crystallite.f90" 7 : basic outputs from the constitutive files 8 : extensive outputs from the constitutive files If verbosity is equal to zero, all counters in debug are not set during calculation (e.g. debug_StressLoopDistribution or debug_cumDotStateTicks). This might speed up parallel calculation, because all these need critical statements which extremely slow down parallel computation.
2011-03-21 16:01:17 +05:30
use mesh, only: mesh_element, &
mesh_NcpElems, &
mesh_maxNips
added a new module called numerics.f90 which reads in all numerical "parameters" from the file numerics.config (also being added). From now on this file has to be located in the working directory of the FEM-model and has to contain all necessary parameters.
2009-06-15 18:41:21 +05:30
use material, only: homogenization_Ngrains
use constitutive, only: constitutive_state0, &
constitutive_partionedState0, &
constitutive_state
quite some changes: # non-greedy memory allocation # generation of outputConstitutive to allow for script-based T16 extraction # exchange of phenomenological by more general phenopowerlaw # lattice is based on slip and twin families which can be treated as individual entities (switched on/off, separate hardening, etc.) # nicer debugging output # changed some error/warning codes # plus potentially some minor additional brushes here and there
2009-07-22 21:37:19 +05:30
use crystallite, only: crystallite_Temperature, &
Major update: corrected treatment of temperature
2009-07-01 15:59:35 +05:30
crystallite_F0, &
Tstar_v is now restored at different stages of cutbacking; we need this because preguess of state relies on consistent Tstar_v
2009-06-16 14:33:30 +05:30
crystallite_Fp0, &
crystallite_Fp, &
crystallite_Lp0, &
crystallite_Lp, &
* now able to choose method for state integration (integrator and integratorStiffness in numerics.config); standard is "Fixed Point Iteration", which is basically the same as before; others available are "Explicit Euler", "AdaptiveEuler", "Classical Runge-Kutta" and "Runge-Kutta Cash-Karp" * now remembering stiffness similar to how we do it for Lp etc.; avoids undefined stiffness values for nonconverged stiffness calculation * non-local stuff: * changed non-local kinetics (Gilman2002) * enforce zero shearrate for overall carrrier density below relevant density * enforce zero density for those states that become negative and were below relevant density before * dislocation velocity is not limited by V^(1/3) / dt anymore
2010-10-01 17:48:49 +05:30
crystallite_dPdF, &
crystallite_dPdF0, &
Tstar_v is now restored at different stages of cutbacking; we need this because preguess of state relies on consistent Tstar_v
2009-06-16 14:33:30 +05:30
crystallite_Tstar0_v, &
quite some changes: # non-greedy memory allocation # generation of outputConstitutive to allow for script-based T16 extraction # exchange of phenomenological by more general phenopowerlaw # lattice is based on slip and twin families which can be treated as individual entities (switched on/off, separate hardening, etc.) # nicer debugging output # changed some error/warning codes # plus potentially some minor additional brushes here and there
2009-07-22 21:37:19 +05:30
crystallite_Tstar_v, &
Major update: corrected treatment of temperature
2009-07-01 15:59:35 +05:30
crystallite_partionedTemperature0, &
Tstar_v is now restored at different stages of cutbacking; we need this because preguess of state relies on consistent Tstar_v
2009-06-16 14:33:30 +05:30
crystallite_partionedF0, &
crystallite_partionedF, &
crystallite_partionedFp0, &
crystallite_partionedLp0, &
* now able to choose method for state integration (integrator and integratorStiffness in numerics.config); standard is "Fixed Point Iteration", which is basically the same as before; others available are "Explicit Euler", "AdaptiveEuler", "Classical Runge-Kutta" and "Runge-Kutta Cash-Karp" * now remembering stiffness similar to how we do it for Lp etc.; avoids undefined stiffness values for nonconverged stiffness calculation * non-local stuff: * changed non-local kinetics (Gilman2002) * enforce zero shearrate for overall carrrier density below relevant density * enforce zero density for those states that become negative and were below relevant density before * dislocation velocity is not limited by V^(1/3) / dt anymore
2010-10-01 17:48:49 +05:30
crystallite_partioneddPdF0, &
Tstar_v is now restored at different stages of cutbacking; we need this because preguess of state relies on consistent Tstar_v
2009-06-16 14:33:30 +05:30
crystallite_partionedTstar0_v, &
crystallite_dt, &
crystallite_requested, &
now with first draft of nonlocal constitutive law debugging memory leak closed debugging counters corrected center of gravity stored in mesh state updated is now split into a collecting loop and an execution updateState and updateTemperature fill sequentially separate logicals and evaluate afterwards to converged added 3x3 transposition function, norm for 3x1 matrix and 33x3 matrix multiplication in math non-converged crystallite triggers materialpoint cutback (used to respond elastically) non-converged materialpoint raises terminal illness which in turn renders whole FE increment useless by means of odd stress/stiffness and thus waits for FE cutback
2009-08-11 22:01:57 +05:30
crystallite_converged, &
new subroutine crystallite_orientations: calculates the orientation matrix and the euler angles and - in case of single grain ips - the misorientation for each neighboring ip. The calculation of the misorientation is now done once in crystallite init and at the end of every FE increment. This saves a lot of time compared to doing it in dotState for every crystallite subinc.
2009-12-18 21:16:33 +05:30
crystallite_stressAndItsTangent, &
crystallite_orientations
debugging output is now controlled by the "verbosity" parameter in the debug.config ranging from 0 (=almost no output) to 8 (=very detailed output) 0 : only version infos and all from "hypela2"/"umat" 1 : basic outputs from "CPFEM.f90", basic output from initialization routines, debug_info 2 : extensive outputs from "CPFEM.f90", extensive output from initialization routines 3 : basic outputs from "homogenization.f90" 4 : extensive outputs from "homogenization.f90" 5 : basic outputs from "crystallite.f90" 6 : extensive outputs from "crystallite.f90" 7 : basic outputs from the constitutive files 8 : extensive outputs from the constitutive files If verbosity is equal to zero, all counters in debug are not set during calculation (e.g. debug_StressLoopDistribution or debug_cumDotStateTicks). This might speed up parallel calculation, because all these need critical statements which extremely slow down parallel computation.
2011-03-21 16:01:17 +05:30
use debug, only: debug_verbosity, &
debug_selectiveDebugger, &
constitutive_nonlocal: - reworked contribution of immobile dislocation density for rate equations - flux is now calculated on the basis of interpolated velocities and densities at the interface; both incoming and outgoing fluxes are considered, so every material point only changes his own dotState - dislocation velocity is now globally defined and calculated by subroutine constitutive_nonlocal_kinetics; the subroutine is called inside _LpAndItsTangent as well as _microstructure; therefore, microstructure now needs Tstar_v as additional input; in the future one should perhaps create a subroutine constitutive_kinetics that calls constitutive_nonlocal_kinetics separately, to clearly distinguish between microstructural and kinetic variables - better use flux density vector as output variable instead of scalar flux values for each interface - added output variables internal and external resolved stress crystallite: - added flag to force local stiffness calculation in case of nonlocal model - misorientation angle is explicitly set to zero when no neighbor can be found debug: - added flag "selectiveDebugger" that is used when debugging statements should only affect a specific element, ip and grain; these are specified with the new variables debug_e, debug_i and debug_g - debugger can now be used in its original sense
2010-02-17 18:51:36 +05:30
debug_e, &
debug_i, &
constitutive_nonlocal.f90 - completed postResults output function - connecting vector of neighboring material points is mapped to intermediate configuration of my neighbor crystallite.f90 - zero out dotState only when crystallite is non-finished - set nonfinished flag to false if crystallite is not on Track after state update - in updateState: set onTrack flag to false if encounter NaN - removed some old debugging outputs and added others homogenization.f90 - in debugging mode now telling when a cutback happens
2009-08-24 13:46:01 +05:30
debug_MaterialpointLoopDistribution, &
now with first draft of nonlocal constitutive law debugging memory leak closed debugging counters corrected center of gravity stored in mesh state updated is now split into a collecting loop and an execution updateState and updateTemperature fill sequentially separate logicals and evaluate afterwards to converged added 3x3 transposition function, norm for 3x1 matrix and 33x3 matrix multiplication in math non-converged crystallite triggers materialpoint cutback (used to respond elastically) non-converged materialpoint raises terminal illness which in turn renders whole FE increment useless by means of odd stress/stiffness and thus waits for FE cutback
2009-08-11 22:01:57 +05:30
debug_MaterialpointStateLoopDistribution
the latest RGC model + corrections for "element homogeneous" feature
2010-03-24 18:50:12 +05:30
use math, only: math_pDecomposition
Tstar_v is now restored at different stages of cutbacking; we need this because preguess of state relies on consistent Tstar_v
2009-06-16 14:33:30 +05:30
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
implicit none
real(pReal), intent(in) :: dt
logical, intent(in) :: updateJaco
now with first draft of nonlocal constitutive law debugging memory leak closed debugging counters corrected center of gravity stored in mesh state updated is now split into a collecting loop and an execution updateState and updateTemperature fill sequentially separate logicals and evaluate afterwards to converged added 3x3 transposition function, norm for 3x1 matrix and 33x3 matrix multiplication in math non-converged crystallite triggers materialpoint cutback (used to respond elastically) non-converged materialpoint raises terminal illness which in turn renders whole FE increment useless by means of odd stress/stiffness and thus waits for FE cutback
2009-08-11 22:01:57 +05:30
integer(pInt) NiterationHomog,NiterationMPstate
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
integer(pInt) g,i,e,myNgrains
the latest RGC model + corrections for "element homogeneous" feature
2010-03-24 18:50:12 +05:30
logical error
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
! ------ initialize to starting condition ------
debugging output is now controlled by the "verbosity" parameter in the debug.config ranging from 0 (=almost no output) to 8 (=very detailed output) 0 : only version infos and all from "hypela2"/"umat" 1 : basic outputs from "CPFEM.f90", basic output from initialization routines, debug_info 2 : extensive outputs from "CPFEM.f90", extensive output from initialization routines 3 : basic outputs from "homogenization.f90" 4 : extensive outputs from "homogenization.f90" 5 : basic outputs from "crystallite.f90" 6 : extensive outputs from "crystallite.f90" 7 : basic outputs from the constitutive files 8 : extensive outputs from the constitutive files If verbosity is equal to zero, all counters in debug are not set during calculation (e.g. debug_StressLoopDistribution or debug_cumDotStateTicks). This might speed up parallel calculation, because all these need critical statements which extremely slow down parallel computation.
2011-03-21 16:01:17 +05:30
if (debug_verbosity > 2 .and. debug_e > 0 .and. debug_e <= mesh_NcpElems .and. debug_i > 0 .and. debug_i <= mesh_maxNips) then
!$OMP CRITICAL (write2out)
write (6,*)
write (6,'(a,i5,x,i2)') '<< HOMOG >> Material Point start at el ip ', debug_e, debug_i
write (6,'(a,/,12(x),f14.9)') '<< HOMOG >> Temp0', materialpoint_Temperature(debug_i,debug_e)
write (6,'(a,/,3(12(x),3(f14.9,x)/))') '<< HOMOG >> F0', math_transpose3x3(materialpoint_F0(1:3,1:3,debug_i,debug_e))
write (6,'(a,/,3(12(x),3(f14.9,x)/))') '<< HOMOG >> F', math_transpose3x3(materialpoint_F(1:3,1:3,debug_i,debug_e))
!$OMP END CRITICAL (write2out)
added flag verboseDebugger to debug in order to have more control about debugging statements set this to true if you want extended debugging info in the output file
2010-03-19 19:44:08 +05:30
endif
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
the latest RGC model + corrections for "element homogeneous" feature
2010-03-24 18:50:12 +05:30
* checked and corrected parallelization of code. compiles now successfully, but simply aborts computation with first parallel directive without any comment :-((( * also put a call to constitutive_microstructure at the start of each crystallite_integration subroutine like it was before. need that for nonlocal model in case of crystallite cutback
2010-11-03 22:52:48 +05:30
!$OMP PARALLEL DO PRIVATE(myNgrains)
Tstar_v is now restored at different stages of cutbacking; we need this because preguess of state relies on consistent Tstar_v
2009-06-16 14:33:30 +05:30
do e = FEsolving_execElem(1),FEsolving_execElem(2) ! iterate over elements to be processed
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
myNgrains = homogenization_Ngrains(mesh_element(3,e))
Tstar_v is now restored at different stages of cutbacking; we need this because preguess of state relies on consistent Tstar_v
2009-06-16 14:33:30 +05:30
do i = FEsolving_execIP(1,e),FEsolving_execIP(2,e) ! iterate over IPs of this element to be processed
! initialize restoration points of grain...
Major update: corrected treatment of temperature
2009-07-01 15:59:35 +05:30
forall (g = 1:myNgrains) constitutive_partionedState0(g,i,e)%p = constitutive_state0(g,i,e)%p ! ...microstructures
quite some changes: # non-greedy memory allocation # generation of outputConstitutive to allow for script-based T16 extraction # exchange of phenomenological by more general phenopowerlaw # lattice is based on slip and twin families which can be treated as individual entities (switched on/off, separate hardening, etc.) # nicer debugging output # changed some error/warning codes # plus potentially some minor additional brushes here and there
2009-07-22 21:37:19 +05:30
crystallite_partionedTemperature0(1:myNgrains,i,e) = materialpoint_Temperature(i,e) ! ...temperatures
openmp parallelization working again (at least for j2 and nonlocal constitutive model). In order to keep it like that, please follow these simple rules: DON'T use implicit array subscripts: example: real, dimension(3,3) :: A,B A(:,2) = B(:,1) <--- DON'T USE A(1:3,2) = B(1:3,1) <--- BETTER USE In many cases the use of explicit array subscripts is inevitable for parallelization. Additionally, it is an easy means to prevent memory leaks. Enclose all write statements with the following: !$OMP CRITICAL (write2out) <your write statement> !$OMP END CRITICAL (write2out) Whenever you change something in the code and are not sure if it affects parallelization and leads to nonconforming behavior, please ask me and/or Franz to check this.
2011-03-17 16:16:17 +05:30
crystallite_partionedFp0(1:3,1:3,1:myNgrains,i,e) = crystallite_Fp0(1:3,1:3,1:myNgrains,i,e) ! ...plastic def grads
crystallite_partionedLp0(1:3,1:3,1:myNgrains,i,e) = crystallite_Lp0(1:3,1:3,1:myNgrains,i,e) ! ...plastic velocity grads
crystallite_partioneddPdF0(1:3,1:3,1:3,1:3,1:myNgrains,i,e) = crystallite_dPdF0(1:3,1:3,1:3,1:3,1:myNgrains,i,e) ! ...stiffness
crystallite_partionedF0(1:3,1:3,1:myNgrains,i,e) = crystallite_F0(1:3,1:3,1:myNgrains,i,e) ! ...def grads
crystallite_partionedTstar0_v(1:6,1:myNgrains,i,e) = crystallite_Tstar0_v(1:6,1:myNgrains,i,e) ! ...2nd PK stress
Tstar_v is now restored at different stages of cutbacking; we need this because preguess of state relies on consistent Tstar_v
2009-06-16 14:33:30 +05:30
! initialize restoration points of ...
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
if (homogenization_sizeState(i,e) > 0_pInt) &
Tstar_v is now restored at different stages of cutbacking; we need this because preguess of state relies on consistent Tstar_v
2009-06-16 14:33:30 +05:30
homogenization_subState0(i,e)%p = homogenization_state0(i,e)%p ! ...internal homogenization state
openmp parallelization working again (at least for j2 and nonlocal constitutive model). In order to keep it like that, please follow these simple rules: DON'T use implicit array subscripts: example: real, dimension(3,3) :: A,B A(:,2) = B(:,1) <--- DON'T USE A(1:3,2) = B(1:3,1) <--- BETTER USE In many cases the use of explicit array subscripts is inevitable for parallelization. Additionally, it is an easy means to prevent memory leaks. Enclose all write statements with the following: !$OMP CRITICAL (write2out) <your write statement> !$OMP END CRITICAL (write2out) Whenever you change something in the code and are not sure if it affects parallelization and leads to nonconforming behavior, please ask me and/or Franz to check this.
2011-03-17 16:16:17 +05:30
materialpoint_subF0(1:3,1:3,i,e) = materialpoint_F0(1:3,1:3,i,e) ! ...def grad
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
materialpoint_subFrac(i,e) = 0.0_pReal
introduced a flexibility in cut-backing scheme in homogenization.f90 and in crystallite.f90: (1) subStepSizeHomog and subStepSizeCryst := size of substep when cut-back is applied (initially was hard-coded). (2) stepIncreaseHomog and stepIncreaseCryst := step increase when calculation for substep converge (was also hardcoded). introduced a possibility to choose different finite difference scheme, i.e., forward-, backward- and central-difference, for computing grain numerical tangent. note that central-difference scheme will slow down the computation significantly. please use it only if necessary. parameters to set these new features have been included in numerics.f90 and numerics.config, whereas corresponding error messages have been introduced in the IO.f90
2009-11-10 19:06:27 +05:30
materialpoint_subStep(i,e) = 1.0_pReal/subStepSizeHomog ! <<added to adopt flexibility in cutback size>>
Tstar_v is now restored at different stages of cutbacking; we need this because preguess of state relies on consistent Tstar_v
2009-06-16 14:33:30 +05:30
materialpoint_converged(i,e) = .false. ! pretend failed step of twice the required size
materialpoint_requested(i,e) = .true. ! everybody requires calculation
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
enddo
enddo
!$OMP END PARALLEL DO
now with first draft of nonlocal constitutive law debugging memory leak closed debugging counters corrected center of gravity stored in mesh state updated is now split into a collecting loop and an execution updateState and updateTemperature fill sequentially separate logicals and evaluate afterwards to converged added 3x3 transposition function, norm for 3x1 matrix and 33x3 matrix multiplication in math non-converged crystallite triggers materialpoint cutback (used to respond elastically) non-converged materialpoint raises terminal illness which in turn renders whole FE increment useless by means of odd stress/stiffness and thus waits for FE cutback
2009-08-11 22:01:57 +05:30
NiterationHomog = 0_pInt
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
! ------ cutback loop ------
1) fixed terminallyIll bug occurring with Ngrains=1 homogenization 2) brushed up the output to be more easily readable/understandable
2010-09-02 02:34:02 +05:30
do while (.not. terminallyIll .and. &
any(materialpoint_subStep(:,FEsolving_execELem(1):FEsolving_execElem(2)) > subStepMinHomog)) ! cutback loop for material points
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
* checked and corrected parallelization of code. compiles now successfully, but simply aborts computation with first parallel directive without any comment :-((( * also put a call to constitutive_microstructure at the start of each crystallite_integration subroutine like it was before. need that for nonlocal model in case of crystallite cutback
2010-11-03 22:52:48 +05:30
!$OMP PARALLEL DO PRIVATE(myNgrains)
1) fixed terminallyIll bug occurring with Ngrains=1 homogenization 2) brushed up the output to be more easily readable/understandable
2010-09-02 02:34:02 +05:30
do e = FEsolving_execElem(1),FEsolving_execElem(2) ! iterate over elements to be processed
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
myNgrains = homogenization_Ngrains(mesh_element(3,e))
1) fixed terminallyIll bug occurring with Ngrains=1 homogenization 2) brushed up the output to be more easily readable/understandable
2010-09-02 02:34:02 +05:30
do i = FEsolving_execIP(1,e),FEsolving_execIP(2,e) ! iterate over IPs of this element to be processed
* checked and corrected parallelization of code. compiles now successfully, but simply aborts computation with first parallel directive without any comment :-((( * also put a call to constitutive_microstructure at the start of each crystallite_integration subroutine like it was before. need that for nonlocal model in case of crystallite cutback
2010-11-03 22:52:48 +05:30
1) fixed terminallyIll bug occurring with Ngrains=1 homogenization 2) brushed up the output to be more easily readable/understandable
2010-09-02 02:34:02 +05:30
if ( materialpoint_converged(i,e) ) then
debugging output is now controlled by the "verbosity" parameter in the debug.config ranging from 0 (=almost no output) to 8 (=very detailed output) 0 : only version infos and all from "hypela2"/"umat" 1 : basic outputs from "CPFEM.f90", basic output from initialization routines, debug_info 2 : extensive outputs from "CPFEM.f90", extensive output from initialization routines 3 : basic outputs from "homogenization.f90" 4 : extensive outputs from "homogenization.f90" 5 : basic outputs from "crystallite.f90" 6 : extensive outputs from "crystallite.f90" 7 : basic outputs from the constitutive files 8 : extensive outputs from the constitutive files If verbosity is equal to zero, all counters in debug are not set during calculation (e.g. debug_StressLoopDistribution or debug_cumDotStateTicks). This might speed up parallel calculation, because all these need critical statements which extremely slow down parallel computation.
2011-03-21 16:01:17 +05:30
if (debug_verbosity > 2 .and. ((e == debug_e .and. i == debug_i) .or. .not. debug_selectiveDebugger)) then
constitutive_nonlocal.f90 - completed postResults output function - connecting vector of neighboring material points is mapped to intermediate configuration of my neighbor crystallite.f90 - zero out dotState only when crystallite is non-finished - set nonfinished flag to false if crystallite is not on Track after state update - in updateState: set onTrack flag to false if encounter NaN - removed some old debugging outputs and added others homogenization.f90 - in debugging mode now telling when a cutback happens
2009-08-24 13:46:01 +05:30
!$OMP CRITICAL (write2out)
debugging output is now controlled by the "verbosity" parameter in the debug.config ranging from 0 (=almost no output) to 8 (=very detailed output) 0 : only version infos and all from "hypela2"/"umat" 1 : basic outputs from "CPFEM.f90", basic output from initialization routines, debug_info 2 : extensive outputs from "CPFEM.f90", extensive output from initialization routines 3 : basic outputs from "homogenization.f90" 4 : extensive outputs from "homogenization.f90" 5 : basic outputs from "crystallite.f90" 6 : extensive outputs from "crystallite.f90" 7 : basic outputs from the constitutive files 8 : extensive outputs from the constitutive files If verbosity is equal to zero, all counters in debug are not set during calculation (e.g. debug_StressLoopDistribution or debug_cumDotStateTicks). This might speed up parallel calculation, because all these need critical statements which extremely slow down parallel computation.
2011-03-21 16:01:17 +05:30
write(6,'(a,x,f10.8,x,a,x,f10.8,x,a,/)') '<< HOMOG >> winding forward from', &
1) fixed terminallyIll bug occurring with Ngrains=1 homogenization 2) brushed up the output to be more easily readable/understandable
2010-09-02 02:34:02 +05:30
materialpoint_subFrac(i,e), 'to current materialpoint_subFrac', &
materialpoint_subFrac(i,e)+materialpoint_subStep(i,e),'in materialpoint_stressAndItsTangent'
* checked and corrected parallelization of code. compiles now successfully, but simply aborts computation with first parallel directive without any comment :-((( * also put a call to constitutive_microstructure at the start of each crystallite_integration subroutine like it was before. need that for nonlocal model in case of crystallite cutback
2010-11-03 22:52:48 +05:30
!$OMP END CRITICAL (write2out)
constitutive_nonlocal.f90 - completed postResults output function - connecting vector of neighboring material points is mapped to intermediate configuration of my neighbor crystallite.f90 - zero out dotState only when crystallite is non-finished - set nonfinished flag to false if crystallite is not on Track after state update - in updateState: set onTrack flag to false if encounter NaN - removed some old debugging outputs and added others homogenization.f90 - in debugging mode now telling when a cutback happens
2009-08-24 13:46:01 +05:30
endif
homogenization_RGC.f90 >>> adding some lines, mostly for debugging purpose. no critical change. constitutive_phenopowerlaw.f90 >>> adding new parameter: constitutive_phenopowerlaw_w0_slip, i.e., the hardening rate exponent. homogenization.f90 >>> most important change is to add an if-else statement (line 379-380) to switch crystallite_requeted = .false. for already converged material point iteration (el/ip). the rest of the changes are cosmetics and debugging stuffs. crystallite.f90 >>> similar to homogenization.f90, the most important change is to add additional if-else statement (line 574) in the jacobian (perturbation) loop. now the jacobian calculation will only be performed when crystallite_requested = .true.. the rest is only cosmetic.
2009-08-27 17:40:06 +05:30
! calculate new subStep and new subFrac
materialpoint_subFrac(i,e) = materialpoint_subFrac(i,e) + materialpoint_subStep(i,e)
openmp parallelization working again (at least for j2 and nonlocal constitutive model). In order to keep it like that, please follow these simple rules: DON'T use implicit array subscripts: example: real, dimension(3,3) :: A,B A(:,2) = B(:,1) <--- DON'T USE A(1:3,2) = B(1:3,1) <--- BETTER USE In many cases the use of explicit array subscripts is inevitable for parallelization. Additionally, it is an easy means to prevent memory leaks. Enclose all write statements with the following: !$OMP CRITICAL (write2out) <your write statement> !$OMP END CRITICAL (write2out) Whenever you change something in the code and are not sure if it affects parallelization and leads to nonconforming behavior, please ask me and/or Franz to check this.
2011-03-17 16:16:17 +05:30
!$OMP FLUSH(materialpoint_subFrac)
introduced a flexibility in cut-backing scheme in homogenization.f90 and in crystallite.f90: (1) subStepSizeHomog and subStepSizeCryst := size of substep when cut-back is applied (initially was hard-coded). (2) stepIncreaseHomog and stepIncreaseCryst := step increase when calculation for substep converge (was also hardcoded). introduced a possibility to choose different finite difference scheme, i.e., forward-, backward- and central-difference, for computing grain numerical tangent. note that central-difference scheme will slow down the computation significantly. please use it only if necessary. parameters to set these new features have been included in numerics.f90 and numerics.config, whereas corresponding error messages have been introduced in the IO.f90
2009-11-10 19:06:27 +05:30
materialpoint_subStep(i,e) = min(1.0_pReal-materialpoint_subFrac(i,e), &
stepIncreaseHomog*materialpoint_subStep(i,e)) ! <<introduce flexibility for step increase/acceleration>>
openmp parallelization working again (at least for j2 and nonlocal constitutive model). In order to keep it like that, please follow these simple rules: DON'T use implicit array subscripts: example: real, dimension(3,3) :: A,B A(:,2) = B(:,1) <--- DON'T USE A(1:3,2) = B(1:3,1) <--- BETTER USE In many cases the use of explicit array subscripts is inevitable for parallelization. Additionally, it is an easy means to prevent memory leaks. Enclose all write statements with the following: !$OMP CRITICAL (write2out) <your write statement> !$OMP END CRITICAL (write2out) Whenever you change something in the code and are not sure if it affects parallelization and leads to nonconforming behavior, please ask me and/or Franz to check this.
2011-03-17 16:16:17 +05:30
!$OMP FLUSH(materialpoint_subStep)
homogenization_RGC.f90 >>> adding some lines, mostly for debugging purpose. no critical change. constitutive_phenopowerlaw.f90 >>> adding new parameter: constitutive_phenopowerlaw_w0_slip, i.e., the hardening rate exponent. homogenization.f90 >>> most important change is to add an if-else statement (line 379-380) to switch crystallite_requeted = .false. for already converged material point iteration (el/ip). the rest of the changes are cosmetics and debugging stuffs. crystallite.f90 >>> similar to homogenization.f90, the most important change is to add additional if-else statement (line 574) in the jacobian (perturbation) loop. now the jacobian calculation will only be performed when crystallite_requested = .true.. the rest is only cosmetic.
2009-08-27 17:40:06 +05:30
Tstar_v is now restored at different stages of cutbacking; we need this because preguess of state relies on consistent Tstar_v
2009-06-16 14:33:30 +05:30
! still stepping needed
minimum substepping size in homogenization and crystallite is now controlled by two independent parameters subStepMinHomog and subStepMinCryst respectively. deleted flush statements where they are not needed, since they seriously slow down computation.
2009-10-26 22:13:43 +05:30
if (materialpoint_subStep(i,e) > subStepMinHomog) then
Tstar_v is now restored at different stages of cutbacking; we need this because preguess of state relies on consistent Tstar_v
2009-06-16 14:33:30 +05:30
! wind forward grain starting point of...
quite some changes: # non-greedy memory allocation # generation of outputConstitutive to allow for script-based T16 extraction # exchange of phenomenological by more general phenopowerlaw # lattice is based on slip and twin families which can be treated as individual entities (switched on/off, separate hardening, etc.) # nicer debugging output # changed some error/warning codes # plus potentially some minor additional brushes here and there
2009-07-22 21:37:19 +05:30
crystallite_partionedTemperature0(1:myNgrains,i,e) = crystallite_Temperature(1:myNgrains,i,e) ! ...temperatures
openmp parallelization working again (at least for j2 and nonlocal constitutive model). In order to keep it like that, please follow these simple rules: DON'T use implicit array subscripts: example: real, dimension(3,3) :: A,B A(:,2) = B(:,1) <--- DON'T USE A(1:3,2) = B(1:3,1) <--- BETTER USE In many cases the use of explicit array subscripts is inevitable for parallelization. Additionally, it is an easy means to prevent memory leaks. Enclose all write statements with the following: !$OMP CRITICAL (write2out) <your write statement> !$OMP END CRITICAL (write2out) Whenever you change something in the code and are not sure if it affects parallelization and leads to nonconforming behavior, please ask me and/or Franz to check this.
2011-03-17 16:16:17 +05:30
crystallite_partionedF0(1:3,1:3,1:myNgrains,i,e) = crystallite_partionedF(1:3,1:3,1:myNgrains,i,e) ! ...def grads
crystallite_partionedFp0(1:3,1:3,1:myNgrains,i,e) = crystallite_Fp(1:3,1:3,1:myNgrains,i,e) ! ...plastic def grads
crystallite_partionedLp0(1:3,1:3,1:myNgrains,i,e) = crystallite_Lp(1:3,1:3,1:myNgrains,i,e) ! ...plastic velocity grads
crystallite_partioneddPdF0(1:3,1:3,1:3,1:3,1:myNgrains,i,e) = crystallite_dPdF(1:3,1:3,1:3,1:3,1:myNgrains,i,e)! ...stiffness
crystallite_partionedTstar0_v(1:6,1:myNgrains,i,e) = crystallite_Tstar_v(1:6,1:myNgrains,i,e) ! ...2nd PK stress
Tstar_v is now restored at different stages of cutbacking; we need this because preguess of state relies on consistent Tstar_v
2009-06-16 14:33:30 +05:30
forall (g = 1:myNgrains) constitutive_partionedState0(g,i,e)%p = constitutive_state(g,i,e)%p ! ...microstructures
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
if (homogenization_sizeState(i,e) > 0_pInt) &
Tstar_v is now restored at different stages of cutbacking; we need this because preguess of state relies on consistent Tstar_v
2009-06-16 14:33:30 +05:30
homogenization_subState0(i,e)%p = homogenization_state(i,e)%p ! ...internal state of homog scheme
openmp parallelization working again (at least for j2 and nonlocal constitutive model). In order to keep it like that, please follow these simple rules: DON'T use implicit array subscripts: example: real, dimension(3,3) :: A,B A(:,2) = B(:,1) <--- DON'T USE A(1:3,2) = B(1:3,1) <--- BETTER USE In many cases the use of explicit array subscripts is inevitable for parallelization. Additionally, it is an easy means to prevent memory leaks. Enclose all write statements with the following: !$OMP CRITICAL (write2out) <your write statement> !$OMP END CRITICAL (write2out) Whenever you change something in the code and are not sure if it affects parallelization and leads to nonconforming behavior, please ask me and/or Franz to check this.
2011-03-17 16:16:17 +05:30
materialpoint_subF0(1:3,1:3,i,e) = materialpoint_subF(1:3,1:3,i,e) ! ...def grad
!$OMP FLUSH(materialpoint_subF0)
material point now cuts back by 1/8 crystallite does not accelerate anymore, since, typically, longer step immediately fails and uses resources in vain. (future: remember number of successful steps to increase step size after x of those...)
2009-10-19 18:20:59 +05:30
elseif (materialpoint_requested(i,e)) then ! this materialpoint just converged ! already at final time (??)
debugging output is now controlled by the "verbosity" parameter in the debug.config ranging from 0 (=almost no output) to 8 (=very detailed output) 0 : only version infos and all from "hypela2"/"umat" 1 : basic outputs from "CPFEM.f90", basic output from initialization routines, debug_info 2 : extensive outputs from "CPFEM.f90", extensive output from initialization routines 3 : basic outputs from "homogenization.f90" 4 : extensive outputs from "homogenization.f90" 5 : basic outputs from "crystallite.f90" 6 : extensive outputs from "crystallite.f90" 7 : basic outputs from the constitutive files 8 : extensive outputs from the constitutive files If verbosity is equal to zero, all counters in debug are not set during calculation (e.g. debug_StressLoopDistribution or debug_cumDotStateTicks). This might speed up parallel calculation, because all these need critical statements which extremely slow down parallel computation.
2011-03-21 16:01:17 +05:30
if (debug_verbosity > 0) then
!$OMP CRITICAL (distributionHomog)
debug_MaterialpointLoopDistribution(min(nHomog+1,NiterationHomog)) = &
debug_MaterialpointLoopDistribution(min(nHomog+1,NiterationHomog)) + 1
!$OMP END CRITICAL (distributionHomog)
endif
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
endif
Tstar_v is now restored at different stages of cutbacking; we need this because preguess of state relies on consistent Tstar_v
2009-06-16 14:33:30 +05:30
! materialpoint didn't converge, so we need a cutback here
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
else
1) fixed terminallyIll bug occurring with Ngrains=1 homogenization 2) brushed up the output to be more easily readable/understandable
2010-09-02 02:34:02 +05:30
if ( (myNgrains == 1_pInt .and. materialpoint_subStep(i,e) <= 1.0 ) .or. & ! single grain already tried internal subStepping in crystallite
subStepSizeHomog * materialpoint_subStep(i,e) <= subStepMinHomog ) then ! would require too small subStep
! cutback makes no sense and...
* checked and corrected parallelization of code. compiles now successfully, but simply aborts computation with first parallel directive without any comment :-((( * also put a call to constitutive_microstructure at the start of each crystallite_integration subroutine like it was before. need that for nonlocal model in case of crystallite cutback
2010-11-03 22:52:48 +05:30
!$OMP CRITICAL (setTerminallyIll)
terminallyIll = .true. ! ...one kills all
!$OMP END CRITICAL (setTerminallyIll)
1) fixed terminallyIll bug occurring with Ngrains=1 homogenization 2) brushed up the output to be more easily readable/understandable
2010-09-02 02:34:02 +05:30
else ! cutback makes sense
materialpoint_subStep(i,e) = subStepSizeHomog * materialpoint_subStep(i,e) ! crystallite had severe trouble, so do a significant cutback
openmp parallelization working again (at least for j2 and nonlocal constitutive model). In order to keep it like that, please follow these simple rules: DON'T use implicit array subscripts: example: real, dimension(3,3) :: A,B A(:,2) = B(:,1) <--- DON'T USE A(1:3,2) = B(1:3,1) <--- BETTER USE In many cases the use of explicit array subscripts is inevitable for parallelization. Additionally, it is an easy means to prevent memory leaks. Enclose all write statements with the following: !$OMP CRITICAL (write2out) <your write statement> !$OMP END CRITICAL (write2out) Whenever you change something in the code and are not sure if it affects parallelization and leads to nonconforming behavior, please ask me and/or Franz to check this.
2011-03-17 16:16:17 +05:30
!$OMP FLUSH(materialpoint_subStep)
1) fixed terminallyIll bug occurring with Ngrains=1 homogenization 2) brushed up the output to be more easily readable/understandable
2010-09-02 02:34:02 +05:30
debugging output is now controlled by the "verbosity" parameter in the debug.config ranging from 0 (=almost no output) to 8 (=very detailed output) 0 : only version infos and all from "hypela2"/"umat" 1 : basic outputs from "CPFEM.f90", basic output from initialization routines, debug_info 2 : extensive outputs from "CPFEM.f90", extensive output from initialization routines 3 : basic outputs from "homogenization.f90" 4 : extensive outputs from "homogenization.f90" 5 : basic outputs from "crystallite.f90" 6 : extensive outputs from "crystallite.f90" 7 : basic outputs from the constitutive files 8 : extensive outputs from the constitutive files If verbosity is equal to zero, all counters in debug are not set during calculation (e.g. debug_StressLoopDistribution or debug_cumDotStateTicks). This might speed up parallel calculation, because all these need critical statements which extremely slow down parallel computation.
2011-03-21 16:01:17 +05:30
if (debug_verbosity > 2 .and. ((e == debug_e .and. i == debug_i) .or. .not. debug_selectiveDebugger)) then
1) fixed terminallyIll bug occurring with Ngrains=1 homogenization 2) brushed up the output to be more easily readable/understandable
2010-09-02 02:34:02 +05:30
!$OMP CRITICAL (write2out)
debugging output is now controlled by the "verbosity" parameter in the debug.config ranging from 0 (=almost no output) to 8 (=very detailed output) 0 : only version infos and all from "hypela2"/"umat" 1 : basic outputs from "CPFEM.f90", basic output from initialization routines, debug_info 2 : extensive outputs from "CPFEM.f90", extensive output from initialization routines 3 : basic outputs from "homogenization.f90" 4 : extensive outputs from "homogenization.f90" 5 : basic outputs from "crystallite.f90" 6 : extensive outputs from "crystallite.f90" 7 : basic outputs from the constitutive files 8 : extensive outputs from the constitutive files If verbosity is equal to zero, all counters in debug are not set during calculation (e.g. debug_StressLoopDistribution or debug_cumDotStateTicks). This might speed up parallel calculation, because all these need critical statements which extremely slow down parallel computation.
2011-03-21 16:01:17 +05:30
write(6,'(a,x,f10.8,/)') '<< HOMOG >> cutback step in materialpoint_stressAndItsTangent with new materialpoint_subStep:',&
1) fixed terminallyIll bug occurring with Ngrains=1 homogenization 2) brushed up the output to be more easily readable/understandable
2010-09-02 02:34:02 +05:30
materialpoint_subStep(i,e)
* checked and corrected parallelization of code. compiles now successfully, but simply aborts computation with first parallel directive without any comment :-((( * also put a call to constitutive_microstructure at the start of each crystallite_integration subroutine like it was before. need that for nonlocal model in case of crystallite cutback
2010-11-03 22:52:48 +05:30
!$OMP END CRITICAL (write2out)
1) fixed terminallyIll bug occurring with Ngrains=1 homogenization 2) brushed up the output to be more easily readable/understandable
2010-09-02 02:34:02 +05:30
endif
! restore...
crystallite_Temperature(1:myNgrains,i,e) = crystallite_partionedTemperature0(1:myNgrains,i,e) ! ...temperatures
! ...initial def grad unchanged
openmp parallelization working again (at least for j2 and nonlocal constitutive model). In order to keep it like that, please follow these simple rules: DON'T use implicit array subscripts: example: real, dimension(3,3) :: A,B A(:,2) = B(:,1) <--- DON'T USE A(1:3,2) = B(1:3,1) <--- BETTER USE In many cases the use of explicit array subscripts is inevitable for parallelization. Additionally, it is an easy means to prevent memory leaks. Enclose all write statements with the following: !$OMP CRITICAL (write2out) <your write statement> !$OMP END CRITICAL (write2out) Whenever you change something in the code and are not sure if it affects parallelization and leads to nonconforming behavior, please ask me and/or Franz to check this.
2011-03-17 16:16:17 +05:30
crystallite_Fp(1:3,1:3,1:myNgrains,i,e) = crystallite_partionedFp0(1:3,1:3,1:myNgrains,i,e) ! ...plastic def grads
crystallite_Lp(1:3,1:3,1:myNgrains,i,e) = crystallite_partionedLp0(1:3,1:3,1:myNgrains,i,e) ! ...plastic velocity grads
crystallite_dPdF(1:3,1:3,1:3,1:3,1:myNgrains,i,e) = crystallite_partioneddPdF0(1:3,1:3,1:3,1:3,1:myNgrains,i,e) ! ...stiffness
crystallite_Tstar_v(1:6,1:myNgrains,i,e) = crystallite_partionedTstar0_v(1:6,1:myNgrains,i,e) ! ...2nd PK stress
1) fixed terminallyIll bug occurring with Ngrains=1 homogenization 2) brushed up the output to be more easily readable/understandable
2010-09-02 02:34:02 +05:30
forall (g = 1:myNgrains) constitutive_state(g,i,e)%p = constitutive_partionedState0(g,i,e)%p ! ...microstructures
if (homogenization_sizeState(i,e) > 0_pInt) &
homogenization_state(i,e)%p = homogenization_subState0(i,e)%p ! ...internal state of homog scheme
endif
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
endif
minimum substepping size in homogenization and crystallite is now controlled by two independent parameters subStepMinHomog and subStepMinCryst respectively. deleted flush statements where they are not needed, since they seriously slow down computation.
2009-10-26 22:13:43 +05:30
materialpoint_requested(i,e) = materialpoint_subStep(i,e) > subStepMinHomog
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
if (materialpoint_requested(i,e)) then
openmp parallelization working again (at least for j2 and nonlocal constitutive model). In order to keep it like that, please follow these simple rules: DON'T use implicit array subscripts: example: real, dimension(3,3) :: A,B A(:,2) = B(:,1) <--- DON'T USE A(1:3,2) = B(1:3,1) <--- BETTER USE In many cases the use of explicit array subscripts is inevitable for parallelization. Additionally, it is an easy means to prevent memory leaks. Enclose all write statements with the following: !$OMP CRITICAL (write2out) <your write statement> !$OMP END CRITICAL (write2out) Whenever you change something in the code and are not sure if it affects parallelization and leads to nonconforming behavior, please ask me and/or Franz to check this.
2011-03-17 16:16:17 +05:30
materialpoint_subF(1:3,1:3,i,e) = materialpoint_subF0(1:3,1:3,i,e) + &
materialpoint_subStep(i,e) * (materialpoint_F(1:3,1:3,i,e) - materialpoint_F0(1:3,1:3,i,e))
materialpoint_subdt(i,e) = materialpoint_subStep(i,e) * dt
materialpoint_doneAndHappy(1:2,i,e) = (/.false.,.true./)
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
endif
1) fixed terminallyIll bug occurring with Ngrains=1 homogenization 2) brushed up the output to be more easily readable/understandable
2010-09-02 02:34:02 +05:30
enddo ! loop IPs
enddo ! loop elements
* checked and corrected parallelization of code. compiles now successfully, but simply aborts computation with first parallel directive without any comment :-((( * also put a call to constitutive_microstructure at the start of each crystallite_integration subroutine like it was before. need that for nonlocal model in case of crystallite cutback
2010-11-03 22:52:48 +05:30
!$OMP END PARALLEL DO
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
List of changes/modifications: * IO.f90 :: Adding error messages for RGC homogenization * crystallite.f90 :: Modifying convergent criteria in crystalline_updateState and crystalline_updateTemperature * material.f90 :: Adding IO_lc in homogenization_type(Name) * debug.f90 :: Adding debbugging statement and counter for material point loop * homogenization.f90 :: Adding homogenization_RGC blocks * homogenization_isostrain.f90 :: Modifying argument of homogenization_isostrain_stateInit * mpie_cpfem_marc.f90 :: Adding homogenization_RGC include * numerics.f90 :: Adding numerical parameters for RGC scheme * math.f90 :: Changing function name: math_permut to math_civita
2009-07-31 17:32:20 +05:30
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
! ------ convergence loop material point homogenization ------
now with first draft of nonlocal constitutive law debugging memory leak closed debugging counters corrected center of gravity stored in mesh state updated is now split into a collecting loop and an execution updateState and updateTemperature fill sequentially separate logicals and evaluate afterwards to converged added 3x3 transposition function, norm for 3x1 matrix and 33x3 matrix multiplication in math non-converged crystallite triggers materialpoint cutback (used to respond elastically) non-converged materialpoint raises terminal illness which in turn renders whole FE increment useless by means of odd stress/stiffness and thus waits for FE cutback
2009-08-11 22:01:57 +05:30
NiterationMPstate = 0_pInt
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
1) fixed terminallyIll bug occurring with Ngrains=1 homogenization 2) brushed up the output to be more easily readable/understandable
2010-09-02 02:34:02 +05:30
do while (.not. terminallyIll .and. &
any( materialpoint_requested(:,FEsolving_execELem(1):FEsolving_execElem(2)) &
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
.and. .not. materialpoint_doneAndHappy(1,:,FEsolving_execELem(1):FEsolving_execElem(2)) &
1) fixed terminallyIll bug occurring with Ngrains=1 homogenization 2) brushed up the output to be more easily readable/understandable
2010-09-02 02:34:02 +05:30
) .and. &
NiterationMPstate < nMPstate) ! convergence loop for materialpoint
now with first draft of nonlocal constitutive law debugging memory leak closed debugging counters corrected center of gravity stored in mesh state updated is now split into a collecting loop and an execution updateState and updateTemperature fill sequentially separate logicals and evaluate afterwards to converged added 3x3 transposition function, norm for 3x1 matrix and 33x3 matrix multiplication in math non-converged crystallite triggers materialpoint cutback (used to respond elastically) non-converged materialpoint raises terminal illness which in turn renders whole FE increment useless by means of odd stress/stiffness and thus waits for FE cutback
2009-08-11 22:01:57 +05:30
NiterationMPstate = NiterationMPstate + 1
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
! --+>> deformation partitioning <<+--
!
! based on materialpoint_subF0,.._subF,
! crystallite_partionedF0,
! homogenization_state
! results in crystallite_partionedF
* checked and corrected parallelization of code. compiles now successfully, but simply aborts computation with first parallel directive without any comment :-((( * also put a call to constitutive_microstructure at the start of each crystallite_integration subroutine like it was before. need that for nonlocal model in case of crystallite cutback
2010-11-03 22:52:48 +05:30
!$OMP PARALLEL DO PRIVATE(myNgrains)
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
do e = FEsolving_execElem(1),FEsolving_execElem(2) ! iterate over elements to be processed
myNgrains = homogenization_Ngrains(mesh_element(3,e))
do i = FEsolving_execIP(1,e),FEsolving_execIP(2,e) ! iterate over IPs of this element to be processed
if ( materialpoint_requested(i,e) .and. & ! process requested but...
.not. materialpoint_doneAndHappy(1,i,e)) then ! ...not yet done material points
call homogenization_partitionDeformation(i,e) ! partition deformation onto constituents
crystallite_dt(1:myNgrains,i,e) = materialpoint_subdt(i,e) ! propagate materialpoint dt to grains
crystallite_requested(1:myNgrains,i,e) = .true. ! request calculation for constituents
homogenization_RGC.f90 >>> adding some lines, mostly for debugging purpose. no critical change. constitutive_phenopowerlaw.f90 >>> adding new parameter: constitutive_phenopowerlaw_w0_slip, i.e., the hardening rate exponent. homogenization.f90 >>> most important change is to add an if-else statement (line 379-380) to switch crystallite_requeted = .false. for already converged material point iteration (el/ip). the rest of the changes are cosmetics and debugging stuffs. crystallite.f90 >>> similar to homogenization.f90, the most important change is to add additional if-else statement (line 574) in the jacobian (perturbation) loop. now the jacobian calculation will only be performed when crystallite_requested = .true.. the rest is only cosmetic.
2009-08-27 17:40:06 +05:30
else
crystallite_requested(1:myNgrains,i,e) = .false. ! calculation for constituents not required anymore
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
endif
enddo
enddo
* checked and corrected parallelization of code. compiles now successfully, but simply aborts computation with first parallel directive without any comment :-((( * also put a call to constitutive_microstructure at the start of each crystallite_integration subroutine like it was before. need that for nonlocal model in case of crystallite cutback
2010-11-03 22:52:48 +05:30
!$OMP END PARALLEL DO
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
! --+>> crystallite integration <<+--
!
! based on crystallite_partionedF0,.._partionedF
! incrementing by crystallite_dt
call crystallite_stressAndItsTangent(updateJaco) ! request stress and tangent calculation for constituent grains
homogenization_RGC.f90 >>> adding some lines, mostly for debugging purpose. no critical change. constitutive_phenopowerlaw.f90 >>> adding new parameter: constitutive_phenopowerlaw_w0_slip, i.e., the hardening rate exponent. homogenization.f90 >>> most important change is to add an if-else statement (line 379-380) to switch crystallite_requeted = .false. for already converged material point iteration (el/ip). the rest of the changes are cosmetics and debugging stuffs. crystallite.f90 >>> similar to homogenization.f90, the most important change is to add additional if-else statement (line 574) in the jacobian (perturbation) loop. now the jacobian calculation will only be performed when crystallite_requested = .true.. the rest is only cosmetic.
2009-08-27 17:40:06 +05:30
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
! --+>> state update <<+--
* checked and corrected parallelization of code. compiles now successfully, but simply aborts computation with first parallel directive without any comment :-((( * also put a call to constitutive_microstructure at the start of each crystallite_integration subroutine like it was before. need that for nonlocal model in case of crystallite cutback
2010-11-03 22:52:48 +05:30
!$OMP PARALLEL DO
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
do e = FEsolving_execElem(1),FEsolving_execElem(2) ! iterate over elements to be processed
do i = FEsolving_execIP(1,e),FEsolving_execIP(2,e) ! iterate over IPs of this element to be processed
if ( materialpoint_requested(i,e) .and. &
.not. materialpoint_doneAndHappy(1,i,e)) then
now with first draft of nonlocal constitutive law debugging memory leak closed debugging counters corrected center of gravity stored in mesh state updated is now split into a collecting loop and an execution updateState and updateTemperature fill sequentially separate logicals and evaluate afterwards to converged added 3x3 transposition function, norm for 3x1 matrix and 33x3 matrix multiplication in math non-converged crystallite triggers materialpoint cutback (used to respond elastically) non-converged materialpoint raises terminal illness which in turn renders whole FE increment useless by means of odd stress/stiffness and thus waits for FE cutback
2009-08-11 22:01:57 +05:30
if (.not. all(crystallite_converged(:,i,e))) then
openmp parallelization working again (at least for j2 and nonlocal constitutive model). In order to keep it like that, please follow these simple rules: DON'T use implicit array subscripts: example: real, dimension(3,3) :: A,B A(:,2) = B(:,1) <--- DON'T USE A(1:3,2) = B(1:3,1) <--- BETTER USE In many cases the use of explicit array subscripts is inevitable for parallelization. Additionally, it is an easy means to prevent memory leaks. Enclose all write statements with the following: !$OMP CRITICAL (write2out) <your write statement> !$OMP END CRITICAL (write2out) Whenever you change something in the code and are not sure if it affects parallelization and leads to nonconforming behavior, please ask me and/or Franz to check this.
2011-03-17 16:16:17 +05:30
materialpoint_doneAndHappy(1:2,i,e) = (/.true.,.false./)
materialpoint_converged(i,e) = .false.
now with first draft of nonlocal constitutive law debugging memory leak closed debugging counters corrected center of gravity stored in mesh state updated is now split into a collecting loop and an execution updateState and updateTemperature fill sequentially separate logicals and evaluate afterwards to converged added 3x3 transposition function, norm for 3x1 matrix and 33x3 matrix multiplication in math non-converged crystallite triggers materialpoint cutback (used to respond elastically) non-converged materialpoint raises terminal illness which in turn renders whole FE increment useless by means of odd stress/stiffness and thus waits for FE cutback
2009-08-11 22:01:57 +05:30
else
openmp parallelization working again (at least for j2 and nonlocal constitutive model). In order to keep it like that, please follow these simple rules: DON'T use implicit array subscripts: example: real, dimension(3,3) :: A,B A(:,2) = B(:,1) <--- DON'T USE A(1:3,2) = B(1:3,1) <--- BETTER USE In many cases the use of explicit array subscripts is inevitable for parallelization. Additionally, it is an easy means to prevent memory leaks. Enclose all write statements with the following: !$OMP CRITICAL (write2out) <your write statement> !$OMP END CRITICAL (write2out) Whenever you change something in the code and are not sure if it affects parallelization and leads to nonconforming behavior, please ask me and/or Franz to check this.
2011-03-17 16:16:17 +05:30
materialpoint_doneAndHappy(1:2,i,e) = homogenization_updateState(i,e)
materialpoint_converged(i,e) = all(homogenization_updateState(i,e)) ! converged if done and happy
now with first draft of nonlocal constitutive law debugging memory leak closed debugging counters corrected center of gravity stored in mesh state updated is now split into a collecting loop and an execution updateState and updateTemperature fill sequentially separate logicals and evaluate afterwards to converged added 3x3 transposition function, norm for 3x1 matrix and 33x3 matrix multiplication in math non-converged crystallite triggers materialpoint cutback (used to respond elastically) non-converged materialpoint raises terminal illness which in turn renders whole FE increment useless by means of odd stress/stiffness and thus waits for FE cutback
2009-08-11 22:01:57 +05:30
endif
openmp parallelization working again (at least for j2 and nonlocal constitutive model). In order to keep it like that, please follow these simple rules: DON'T use implicit array subscripts: example: real, dimension(3,3) :: A,B A(:,2) = B(:,1) <--- DON'T USE A(1:3,2) = B(1:3,1) <--- BETTER USE In many cases the use of explicit array subscripts is inevitable for parallelization. Additionally, it is an easy means to prevent memory leaks. Enclose all write statements with the following: !$OMP CRITICAL (write2out) <your write statement> !$OMP END CRITICAL (write2out) Whenever you change something in the code and are not sure if it affects parallelization and leads to nonconforming behavior, please ask me and/or Franz to check this.
2011-03-17 16:16:17 +05:30
!$OMP FLUSH(materialpoint_converged)
* checked and corrected parallelization of code. compiles now successfully, but simply aborts computation with first parallel directive without any comment :-((( * also put a call to constitutive_microstructure at the start of each crystallite_integration subroutine like it was before. need that for nonlocal model in case of crystallite cutback
2010-11-03 22:52:48 +05:30
if (materialpoint_converged(i,e)) then
debugging output is now controlled by the "verbosity" parameter in the debug.config ranging from 0 (=almost no output) to 8 (=very detailed output) 0 : only version infos and all from "hypela2"/"umat" 1 : basic outputs from "CPFEM.f90", basic output from initialization routines, debug_info 2 : extensive outputs from "CPFEM.f90", extensive output from initialization routines 3 : basic outputs from "homogenization.f90" 4 : extensive outputs from "homogenization.f90" 5 : basic outputs from "crystallite.f90" 6 : extensive outputs from "crystallite.f90" 7 : basic outputs from the constitutive files 8 : extensive outputs from the constitutive files If verbosity is equal to zero, all counters in debug are not set during calculation (e.g. debug_StressLoopDistribution or debug_cumDotStateTicks). This might speed up parallel calculation, because all these need critical statements which extremely slow down parallel computation.
2011-03-21 16:01:17 +05:30
if (debug_verbosity > 0) then
!$OMP CRITICAL (distributionMPState)
debug_MaterialpointStateLoopdistribution(NiterationMPstate) = &
debug_MaterialpointStateLoopdistribution(NiterationMPstate) + 1
!$OMP END CRITICAL (distributionMPState)
endif
* checked and corrected parallelization of code. compiles now successfully, but simply aborts computation with first parallel directive without any comment :-((( * also put a call to constitutive_microstructure at the start of each crystallite_integration subroutine like it was before. need that for nonlocal model in case of crystallite cutback
2010-11-03 22:52:48 +05:30
endif
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
endif
enddo
enddo
* checked and corrected parallelization of code. compiles now successfully, but simply aborts computation with first parallel directive without any comment :-((( * also put a call to constitutive_microstructure at the start of each crystallite_integration subroutine like it was before. need that for nonlocal model in case of crystallite cutback
2010-11-03 22:52:48 +05:30
!$OMP END PARALLEL DO
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
enddo ! homogenization convergence loop
* now able to choose method for state integration (integrator and integratorStiffness in numerics.config); standard is "Fixed Point Iteration", which is basically the same as before; others available are "Explicit Euler", "AdaptiveEuler", "Classical Runge-Kutta" and "Runge-Kutta Cash-Karp" * now remembering stiffness similar to how we do it for Lp etc.; avoids undefined stiffness values for nonconverged stiffness calculation * non-local stuff: * changed non-local kinetics (Gilman2002) * enforce zero shearrate for overall carrrier density below relevant density * enforce zero density for those states that become negative and were below relevant density before * dislocation velocity is not limited by V^(1/3) / dt anymore
2010-10-01 17:48:49 +05:30
NiterationHomog = NiterationHomog + 1_pInt
now with first draft of nonlocal constitutive law debugging memory leak closed debugging counters corrected center of gravity stored in mesh state updated is now split into a collecting loop and an execution updateState and updateTemperature fill sequentially separate logicals and evaluate afterwards to converged added 3x3 transposition function, norm for 3x1 matrix and 33x3 matrix multiplication in math non-converged crystallite triggers materialpoint cutback (used to respond elastically) non-converged materialpoint raises terminal illness which in turn renders whole FE increment useless by means of odd stress/stiffness and thus waits for FE cutback
2009-08-11 22:01:57 +05:30
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
enddo ! cutback loop
1) fixed terminallyIll bug occurring with Ngrains=1 homogenization 2) brushed up the output to be more easily readable/understandable
2010-09-02 02:34:02 +05:30
if (.not. terminallyIll ) then
* now able to choose method for state integration (integrator and integratorStiffness in numerics.config); standard is "Fixed Point Iteration", which is basically the same as before; others available are "Explicit Euler", "AdaptiveEuler", "Classical Runge-Kutta" and "Runge-Kutta Cash-Karp" * now remembering stiffness similar to how we do it for Lp etc.; avoids undefined stiffness values for nonconverged stiffness calculation * non-local stuff: * changed non-local kinetics (Gilman2002) * enforce zero shearrate for overall carrrier density below relevant density * enforce zero density for those states that become negative and were below relevant density before * dislocation velocity is not limited by V^(1/3) / dt anymore
2010-10-01 17:48:49 +05:30
1) fixed terminallyIll bug occurring with Ngrains=1 homogenization 2) brushed up the output to be more easily readable/understandable
2010-09-02 02:34:02 +05:30
call crystallite_orientations() ! calculate crystal orientations
* checked and corrected parallelization of code. compiles now successfully, but simply aborts computation with first parallel directive without any comment :-((( * also put a call to constitutive_microstructure at the start of each crystallite_integration subroutine like it was before. need that for nonlocal model in case of crystallite cutback
2010-11-03 22:52:48 +05:30
!$OMP PARALLEL DO
1) fixed terminallyIll bug occurring with Ngrains=1 homogenization 2) brushed up the output to be more easily readable/understandable
2010-09-02 02:34:02 +05:30
do e = FEsolving_execElem(1),FEsolving_execElem(2) ! iterate over elements to be processed
do i = FEsolving_execIP(1,e),FEsolving_execIP(2,e) ! iterate over IPs of this element to be processed
now with first draft of nonlocal constitutive law debugging memory leak closed debugging counters corrected center of gravity stored in mesh state updated is now split into a collecting loop and an execution updateState and updateTemperature fill sequentially separate logicals and evaluate afterwards to converged added 3x3 transposition function, norm for 3x1 matrix and 33x3 matrix multiplication in math non-converged crystallite triggers materialpoint cutback (used to respond elastically) non-converged materialpoint raises terminal illness which in turn renders whole FE increment useless by means of odd stress/stiffness and thus waits for FE cutback
2009-08-11 22:01:57 +05:30
call homogenization_averageStressAndItsTangent(i,e)
new subroutine crystallite_orientations: calculates the orientation matrix and the euler angles and - in case of single grain ips - the misorientation for each neighboring ip. The calculation of the misorientation is now done once in crystallite init and at the end of every FE increment. This saves a lot of time compared to doing it in dotState for every crystallite subinc.
2009-12-18 21:16:33 +05:30
call homogenization_averageTemperature(i,e)
1) fixed terminallyIll bug occurring with Ngrains=1 homogenization 2) brushed up the output to be more easily readable/understandable
2010-09-02 02:34:02 +05:30
enddo; enddo
* checked and corrected parallelization of code. compiles now successfully, but simply aborts computation with first parallel directive without any comment :-((( * also put a call to constitutive_microstructure at the start of each crystallite_integration subroutine like it was before. need that for nonlocal model in case of crystallite cutback
2010-11-03 22:52:48 +05:30
!$OMP END PARALLEL DO
1) fixed terminallyIll bug occurring with Ngrains=1 homogenization 2) brushed up the output to be more easily readable/understandable
2010-09-02 02:34:02 +05:30
debugging output is now controlled by the "verbosity" parameter in the debug.config ranging from 0 (=almost no output) to 8 (=very detailed output) 0 : only version infos and all from "hypela2"/"umat" 1 : basic outputs from "CPFEM.f90", basic output from initialization routines, debug_info 2 : extensive outputs from "CPFEM.f90", extensive output from initialization routines 3 : basic outputs from "homogenization.f90" 4 : extensive outputs from "homogenization.f90" 5 : basic outputs from "crystallite.f90" 6 : extensive outputs from "crystallite.f90" 7 : basic outputs from the constitutive files 8 : extensive outputs from the constitutive files If verbosity is equal to zero, all counters in debug are not set during calculation (e.g. debug_StressLoopDistribution or debug_cumDotStateTicks). This might speed up parallel calculation, because all these need critical statements which extremely slow down parallel computation.
2011-03-21 16:01:17 +05:30
if (debug_verbosity > 2) then
!$OMP CRITICAL (write2out)
write (6,*)
write (6,'(a)') '<< HOMOG >> Material Point end'
write (6,*)
!$OMP END CRITICAL (write2out)
1) fixed terminallyIll bug occurring with Ngrains=1 homogenization 2) brushed up the output to be more easily readable/understandable
2010-09-02 02:34:02 +05:30
endif
else
debugging output is now controlled by the "verbosity" parameter in the debug.config ranging from 0 (=almost no output) to 8 (=very detailed output) 0 : only version infos and all from "hypela2"/"umat" 1 : basic outputs from "CPFEM.f90", basic output from initialization routines, debug_info 2 : extensive outputs from "CPFEM.f90", extensive output from initialization routines 3 : basic outputs from "homogenization.f90" 4 : extensive outputs from "homogenization.f90" 5 : basic outputs from "crystallite.f90" 6 : extensive outputs from "crystallite.f90" 7 : basic outputs from the constitutive files 8 : extensive outputs from the constitutive files If verbosity is equal to zero, all counters in debug are not set during calculation (e.g. debug_StressLoopDistribution or debug_cumDotStateTicks). This might speed up parallel calculation, because all these need critical statements which extremely slow down parallel computation.
2011-03-21 16:01:17 +05:30
!$OMP CRITICAL (write2out)
write (6,*)
write (6,'(a)') '<< HOMOG >> Material Point terminally ill'
write (6,*)
!$OMP END CRITICAL (write2out)
1) fixed terminallyIll bug occurring with Ngrains=1 homogenization 2) brushed up the output to be more easily readable/understandable
2010-09-02 02:34:02 +05:30
added flag verboseDebugger to debug in order to have more control about debugging statements set this to true if you want extended debugging info in the output file
2010-03-19 19:44:08 +05:30
endif
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
return
added a new module called numerics.f90 which reads in all numerical "parameters" from the file numerics.config (also being added). From now on this file has to be located in the working directory of the FEM-model and has to contain all necessary parameters.
2009-06-15 18:41:21 +05:30
endsubroutine
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
!********************************************************************
!* parallelized calculation of
!* result array at material points
!********************************************************************
subroutine materialpoint_postResults(dt)
use FEsolving, only: FEsolving_execElem, FEsolving_execIP
use mesh, only: mesh_element
reworked crystallite part to allow for flexible user output --> new "crystallite" part in config file --> new "crystallite" option for microstructures --> new output file "...job.outputCrystallite" to be used in conjunction with marc_addUserOutput for meaningful naming of User Defined Vars.
2010-02-25 23:09:11 +05:30
use material, only: homogenization_Ngrains, microstructure_crystallite
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
use constitutive, only: constitutive_sizePostResults, constitutive_postResults
reworked crystallite part to allow for flexible user output --> new "crystallite" part in config file --> new "crystallite" option for microstructures --> new output file "...job.outputCrystallite" to be used in conjunction with marc_addUserOutput for meaningful naming of User Defined Vars.
2010-02-25 23:09:11 +05:30
use crystallite, only: crystallite_sizePostResults, crystallite_postResults
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
implicit none
real(pReal), intent(in) :: dt
reworked crystallite part to allow for flexible user output --> new "crystallite" part in config file --> new "crystallite" option for microstructures --> new output file "...job.outputCrystallite" to be used in conjunction with marc_addUserOutput for meaningful naming of User Defined Vars.
2010-02-25 23:09:11 +05:30
integer(pInt) g,i,e,c,d,myNgrains,myCrystallite
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
* checked and corrected parallelization of code. compiles now successfully, but simply aborts computation with first parallel directive without any comment :-((( * also put a call to constitutive_microstructure at the start of each crystallite_integration subroutine like it was before. need that for nonlocal model in case of crystallite cutback
2010-11-03 22:52:48 +05:30
!$OMP PARALLEL DO PRIVATE(myNgrains,myCrystallite,c,d)
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
do e = FEsolving_execElem(1),FEsolving_execElem(2) ! iterate over elements to be processed
myNgrains = homogenization_Ngrains(mesh_element(3,e))
reworked crystallite part to allow for flexible user output --> new "crystallite" part in config file --> new "crystallite" option for microstructures --> new output file "...job.outputCrystallite" to be used in conjunction with marc_addUserOutput for meaningful naming of User Defined Vars.
2010-02-25 23:09:11 +05:30
myCrystallite = microstructure_crystallite(mesh_element(4,e))
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
do i = FEsolving_execIP(1,e),FEsolving_execIP(2,e) ! iterate over IPs of this element to be processed
c = 0_pInt
quite some changes: # non-greedy memory allocation # generation of outputConstitutive to allow for script-based T16 extraction # exchange of phenomenological by more general phenopowerlaw # lattice is based on slip and twin families which can be treated as individual entities (switched on/off, separate hardening, etc.) # nicer debugging output # changed some error/warning codes # plus potentially some minor additional brushes here and there
2009-07-22 21:37:19 +05:30
materialpoint_results(c+1,i,e) = myNgrains; c = c+1_pInt ! tell number of grains at materialpoint
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
d = homogenization_sizePostResults(i,e)
materialpoint_results(c+1,i,e) = d; c = c+1_pInt ! tell size of homogenization results
quite some changes: # non-greedy memory allocation # generation of outputConstitutive to allow for script-based T16 extraction # exchange of phenomenological by more general phenopowerlaw # lattice is based on slip and twin families which can be treated as individual entities (switched on/off, separate hardening, etc.) # nicer debugging output # changed some error/warning codes # plus potentially some minor additional brushes here and there
2009-07-22 21:37:19 +05:30
if (d > 0_pInt) then ! any homogenization results to mention?
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
materialpoint_results(c+1:c+d,i,e) = & ! tell homogenization results
constitutive_nonlocal: - read in activation energy for dislocation glide from material.config - changed naming of dDipMin/Max to dLower/dUpper - added new outputs: rho_dot, rho_dot_dip, rho_dot_gen, rho_dot_sgl2dip, rho_dot_dip2sgl, rho_dot_ann_ath, rho_dot_ann_the, rho_dot_flux, d_upper_edge, d_upper_screw, d_upper_dot_edge, d_upper_dot_screw - poisson's ratio is now calculated from elastic constants - microstrucutre has state as first argument, since this is our output variable - periodic boundary conditions are taken into account for fluxes and internal stresses. for the moment, flag has to be set in constitutive_nonlocal. - corrected calculation for dipole formation by glide - added terms for dipole formation/annihilation by stress decrease/increase constitutive: - passing of arguments is adapted for constitutive_nonlocal model crystallite: - in stiffness calculation: call to collect_dotState used wrong arguments - crystallite_postResults uses own Tstar_v and temperature, no need for passing them from materialpoint_postResults homogenization: - crystallite_postResults uses own Tstar_v and temperature, no need for passing them from materialpoint_postResults IO: - changed error message 229 material.config: - changed example for nonlocal constitution according to constitutive_nonlocal all: - added some flush statements
2009-10-20 20:06:03 +05:30
homogenization_postResults(i,e); c = c+d
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
endif
sorry, back to the previous version. grain deformation output is part of crystallite.f90, no longer done by homogenization. material.config reflects the changes.
2009-10-22 22:29:24 +05:30
do g = 1,myNgrains ! loop over all grains
reworked crystallite part to allow for flexible user output --> new "crystallite" part in config file --> new "crystallite" option for microstructures --> new output file "...job.outputCrystallite" to be used in conjunction with marc_addUserOutput for meaningful naming of User Defined Vars.
2010-02-25 23:09:11 +05:30
d = 1+crystallite_sizePostResults(myCrystallite) + 1+constitutive_sizePostResults(g,i,e)
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
materialpoint_results(c+1:c+d,i,e) = & ! tell crystallite results
constitutive_nonlocal: - read in activation energy for dislocation glide from material.config - changed naming of dDipMin/Max to dLower/dUpper - added new outputs: rho_dot, rho_dot_dip, rho_dot_gen, rho_dot_sgl2dip, rho_dot_dip2sgl, rho_dot_ann_ath, rho_dot_ann_the, rho_dot_flux, d_upper_edge, d_upper_screw, d_upper_dot_edge, d_upper_dot_screw - poisson's ratio is now calculated from elastic constants - microstrucutre has state as first argument, since this is our output variable - periodic boundary conditions are taken into account for fluxes and internal stresses. for the moment, flag has to be set in constitutive_nonlocal. - corrected calculation for dipole formation by glide - added terms for dipole formation/annihilation by stress decrease/increase constitutive: - passing of arguments is adapted for constitutive_nonlocal model crystallite: - in stiffness calculation: call to collect_dotState used wrong arguments - crystallite_postResults uses own Tstar_v and temperature, no need for passing them from materialpoint_postResults homogenization: - crystallite_postResults uses own Tstar_v and temperature, no need for passing them from materialpoint_postResults IO: - changed error message 229 material.config: - changed example for nonlocal constitution according to constitutive_nonlocal all: - added some flush statements
2009-10-20 20:06:03 +05:30
crystallite_postResults(dt,g,i,e); c = c+d
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
enddo
enddo
enddo
* checked and corrected parallelization of code. compiles now successfully, but simply aborts computation with first parallel directive without any comment :-((( * also put a call to constitutive_microstructure at the start of each crystallite_integration subroutine like it was before. need that for nonlocal model in case of crystallite cutback
2010-11-03 22:52:48 +05:30
!$OMP END PARALLEL DO
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
added a new module called numerics.f90 which reads in all numerical "parameters" from the file numerics.config (also being added). From now on this file has to be located in the working directory of the FEM-model and has to contain all necessary parameters.
2009-06-15 18:41:21 +05:30
endsubroutine
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
!********************************************************************
! partition material point def grad onto constituents
!********************************************************************
subroutine homogenization_partitionDeformation(&
ip, & ! integration point
el & ! element
)
use prec, only: pReal,pInt
use mesh, only: mesh_element
use material, only: homogenization_type, homogenization_maxNgrains
use crystallite, only: crystallite_partionedF0,crystallite_partionedF
use homogenization_isostrain
openmp parallelization working again (at least for j2 and nonlocal constitutive model). In order to keep it like that, please follow these simple rules: DON'T use implicit array subscripts: example: real, dimension(3,3) :: A,B A(:,2) = B(:,1) <--- DON'T USE A(1:3,2) = B(1:3,1) <--- BETTER USE In many cases the use of explicit array subscripts is inevitable for parallelization. Additionally, it is an easy means to prevent memory leaks. Enclose all write statements with the following: !$OMP CRITICAL (write2out) <your write statement> !$OMP END CRITICAL (write2out) Whenever you change something in the code and are not sure if it affects parallelization and leads to nonconforming behavior, please ask me and/or Franz to check this.
2011-03-17 16:16:17 +05:30
use homogenization_RGC
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
implicit none
integer(pInt), intent(in) :: ip,el
select case(homogenization_type(mesh_element(3,el)))
case (homogenization_isostrain_label)
List of changes/modifications: * IO.f90 :: Adding error messages for RGC homogenization * crystallite.f90 :: Modifying convergent criteria in crystalline_updateState and crystalline_updateTemperature * material.f90 :: Adding IO_lc in homogenization_type(Name) * debug.f90 :: Adding debbugging statement and counter for material point loop * homogenization.f90 :: Adding homogenization_RGC blocks * homogenization_isostrain.f90 :: Modifying argument of homogenization_isostrain_stateInit * mpie_cpfem_marc.f90 :: Adding homogenization_RGC include * numerics.f90 :: Adding numerical parameters for RGC scheme * math.f90 :: Changing function name: math_permut to math_civita
2009-07-31 17:32:20 +05:30
!* isostrain
openmp parallelization working again (at least for j2 and nonlocal constitutive model). In order to keep it like that, please follow these simple rules: DON'T use implicit array subscripts: example: real, dimension(3,3) :: A,B A(:,2) = B(:,1) <--- DON'T USE A(1:3,2) = B(1:3,1) <--- BETTER USE In many cases the use of explicit array subscripts is inevitable for parallelization. Additionally, it is an easy means to prevent memory leaks. Enclose all write statements with the following: !$OMP CRITICAL (write2out) <your write statement> !$OMP END CRITICAL (write2out) Whenever you change something in the code and are not sure if it affects parallelization and leads to nonconforming behavior, please ask me and/or Franz to check this.
2011-03-17 16:16:17 +05:30
call homogenization_isostrain_partitionDeformation(crystallite_partionedF(1:3,1:3,1:homogenization_maxNgrains,ip,el), &
crystallite_partionedF0(1:3,1:3,1:homogenization_maxNgrains,ip,el),&
materialpoint_subF(1:3,1:3,ip,el),&
Tstar_v is now restored at different stages of cutbacking; we need this because preguess of state relies on consistent Tstar_v
2009-06-16 14:33:30 +05:30
homogenization_state(ip,el), &
ip, &
el)
openmp parallelization working again (at least for j2 and nonlocal constitutive model). In order to keep it like that, please follow these simple rules: DON'T use implicit array subscripts: example: real, dimension(3,3) :: A,B A(:,2) = B(:,1) <--- DON'T USE A(1:3,2) = B(1:3,1) <--- BETTER USE In many cases the use of explicit array subscripts is inevitable for parallelization. Additionally, it is an easy means to prevent memory leaks. Enclose all write statements with the following: !$OMP CRITICAL (write2out) <your write statement> !$OMP END CRITICAL (write2out) Whenever you change something in the code and are not sure if it affects parallelization and leads to nonconforming behavior, please ask me and/or Franz to check this.
2011-03-17 16:16:17 +05:30
!* RGC homogenization
List of changes/modifications: * IO.f90 :: Adding error messages for RGC homogenization * crystallite.f90 :: Modifying convergent criteria in crystalline_updateState and crystalline_updateTemperature * material.f90 :: Adding IO_lc in homogenization_type(Name) * debug.f90 :: Adding debbugging statement and counter for material point loop * homogenization.f90 :: Adding homogenization_RGC blocks * homogenization_isostrain.f90 :: Modifying argument of homogenization_isostrain_stateInit * mpie_cpfem_marc.f90 :: Adding homogenization_RGC include * numerics.f90 :: Adding numerical parameters for RGC scheme * math.f90 :: Changing function name: math_permut to math_civita
2009-07-31 17:32:20 +05:30
case (homogenization_RGC_label)
openmp parallelization working again (at least for j2 and nonlocal constitutive model). In order to keep it like that, please follow these simple rules: DON'T use implicit array subscripts: example: real, dimension(3,3) :: A,B A(:,2) = B(:,1) <--- DON'T USE A(1:3,2) = B(1:3,1) <--- BETTER USE In many cases the use of explicit array subscripts is inevitable for parallelization. Additionally, it is an easy means to prevent memory leaks. Enclose all write statements with the following: !$OMP CRITICAL (write2out) <your write statement> !$OMP END CRITICAL (write2out) Whenever you change something in the code and are not sure if it affects parallelization and leads to nonconforming behavior, please ask me and/or Franz to check this.
2011-03-17 16:16:17 +05:30
call homogenization_RGC_partitionDeformation(crystallite_partionedF(1:3,1:3,1:homogenization_maxNgrains,ip,el), &
crystallite_partionedF0(1:3,1:3,1:homogenization_maxNgrains,ip,el),&
materialpoint_subF(1:3,1:3,ip,el),&
List of changes/modifications: * IO.f90 :: Adding error messages for RGC homogenization * crystallite.f90 :: Modifying convergent criteria in crystalline_updateState and crystalline_updateTemperature * material.f90 :: Adding IO_lc in homogenization_type(Name) * debug.f90 :: Adding debbugging statement and counter for material point loop * homogenization.f90 :: Adding homogenization_RGC blocks * homogenization_isostrain.f90 :: Modifying argument of homogenization_isostrain_stateInit * mpie_cpfem_marc.f90 :: Adding homogenization_RGC include * numerics.f90 :: Adding numerical parameters for RGC scheme * math.f90 :: Changing function name: math_permut to math_civita
2009-07-31 17:32:20 +05:30
homogenization_state(ip,el), &
ip, &
el)
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
end select
added a new module called numerics.f90 which reads in all numerical "parameters" from the file numerics.config (also being added). From now on this file has to be located in the working directory of the FEM-model and has to contain all necessary parameters.
2009-06-15 18:41:21 +05:30
endsubroutine
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
!********************************************************************
! update the internal state of the homogenization scheme
! and tell whether "done" and "happy" with result
!********************************************************************
function homogenization_updateState(&
ip, & ! integration point
el & ! element
)
use prec, only: pReal,pInt
use mesh, only: mesh_element
use material, only: homogenization_type, homogenization_maxNgrains
List of changes/modifications: * IO.f90 :: Adding error messages for RGC homogenization * crystallite.f90 :: Modifying convergent criteria in crystalline_updateState and crystalline_updateTemperature * material.f90 :: Adding IO_lc in homogenization_type(Name) * debug.f90 :: Adding debbugging statement and counter for material point loop * homogenization.f90 :: Adding homogenization_RGC blocks * homogenization_isostrain.f90 :: Modifying argument of homogenization_isostrain_stateInit * mpie_cpfem_marc.f90 :: Adding homogenization_RGC include * numerics.f90 :: Adding numerical parameters for RGC scheme * math.f90 :: Changing function name: math_permut to math_civita
2009-07-31 17:32:20 +05:30
use crystallite, only: crystallite_P,crystallite_dPdF,crystallite_partionedF,crystallite_partionedF0 ! modified <<<updated 31.07.2009>>>
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
use homogenization_isostrain
openmp parallelization working again (at least for j2 and nonlocal constitutive model). In order to keep it like that, please follow these simple rules: DON'T use implicit array subscripts: example: real, dimension(3,3) :: A,B A(:,2) = B(:,1) <--- DON'T USE A(1:3,2) = B(1:3,1) <--- BETTER USE In many cases the use of explicit array subscripts is inevitable for parallelization. Additionally, it is an easy means to prevent memory leaks. Enclose all write statements with the following: !$OMP CRITICAL (write2out) <your write statement> !$OMP END CRITICAL (write2out) Whenever you change something in the code and are not sure if it affects parallelization and leads to nonconforming behavior, please ask me and/or Franz to check this.
2011-03-17 16:16:17 +05:30
use homogenization_RGC
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
implicit none
integer(pInt), intent(in) :: ip,el
logical, dimension(2) :: homogenization_updateState
select case(homogenization_type(mesh_element(3,el)))
List of changes/modifications: * IO.f90 :: Adding error messages for RGC homogenization * crystallite.f90 :: Modifying convergent criteria in crystalline_updateState and crystalline_updateTemperature * material.f90 :: Adding IO_lc in homogenization_type(Name) * debug.f90 :: Adding debbugging statement and counter for material point loop * homogenization.f90 :: Adding homogenization_RGC blocks * homogenization_isostrain.f90 :: Modifying argument of homogenization_isostrain_stateInit * mpie_cpfem_marc.f90 :: Adding homogenization_RGC include * numerics.f90 :: Adding numerical parameters for RGC scheme * math.f90 :: Changing function name: math_permut to math_civita
2009-07-31 17:32:20 +05:30
!* isostrain
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
case (homogenization_isostrain_label)
openmp parallelization working again (at least for j2 and nonlocal constitutive model). In order to keep it like that, please follow these simple rules: DON'T use implicit array subscripts: example: real, dimension(3,3) :: A,B A(:,2) = B(:,1) <--- DON'T USE A(1:3,2) = B(1:3,1) <--- BETTER USE In many cases the use of explicit array subscripts is inevitable for parallelization. Additionally, it is an easy means to prevent memory leaks. Enclose all write statements with the following: !$OMP CRITICAL (write2out) <your write statement> !$OMP END CRITICAL (write2out) Whenever you change something in the code and are not sure if it affects parallelization and leads to nonconforming behavior, please ask me and/or Franz to check this.
2011-03-17 16:16:17 +05:30
homogenization_updateState = &
homogenization_isostrain_updateState( homogenization_state(ip,el), &
crystallite_P(1:3,1:3,1:homogenization_maxNgrains,ip,el), &
crystallite_dPdF(1:3,1:3,1:3,1:3,1:homogenization_maxNgrains,ip,el), &
ip, &
el)
!* RGC homogenization
List of changes/modifications: * IO.f90 :: Adding error messages for RGC homogenization * crystallite.f90 :: Modifying convergent criteria in crystalline_updateState and crystalline_updateTemperature * material.f90 :: Adding IO_lc in homogenization_type(Name) * debug.f90 :: Adding debbugging statement and counter for material point loop * homogenization.f90 :: Adding homogenization_RGC blocks * homogenization_isostrain.f90 :: Modifying argument of homogenization_isostrain_stateInit * mpie_cpfem_marc.f90 :: Adding homogenization_RGC include * numerics.f90 :: Adding numerical parameters for RGC scheme * math.f90 :: Changing function name: math_permut to math_civita
2009-07-31 17:32:20 +05:30
case (homogenization_RGC_label)
openmp parallelization working again (at least for j2 and nonlocal constitutive model). In order to keep it like that, please follow these simple rules: DON'T use implicit array subscripts: example: real, dimension(3,3) :: A,B A(:,2) = B(:,1) <--- DON'T USE A(1:3,2) = B(1:3,1) <--- BETTER USE In many cases the use of explicit array subscripts is inevitable for parallelization. Additionally, it is an easy means to prevent memory leaks. Enclose all write statements with the following: !$OMP CRITICAL (write2out) <your write statement> !$OMP END CRITICAL (write2out) Whenever you change something in the code and are not sure if it affects parallelization and leads to nonconforming behavior, please ask me and/or Franz to check this.
2011-03-17 16:16:17 +05:30
homogenization_updateState = &
homogenization_RGC_updateState( homogenization_state(ip,el), &
homogenization_subState0(ip,el), &
crystallite_P(1:3,1:3,1:homogenization_maxNgrains,ip,el), &
crystallite_partionedF(1:3,1:3,1:homogenization_maxNgrains,ip,el), &
crystallite_partionedF0(1:3,1:3,1:homogenization_maxNgrains,ip,el),&
materialpoint_subF(1:3,1:3,ip,el),&
materialpoint_subdt(ip,el), &
crystallite_dPdF(1:3,1:3,1:3,1:3,1:homogenization_maxNgrains,ip,el), &
ip, &
el)
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
end select
return
added a new module called numerics.f90 which reads in all numerical "parameters" from the file numerics.config (also being added). From now on this file has to be located in the working directory of the FEM-model and has to contain all necessary parameters.
2009-06-15 18:41:21 +05:30
endfunction
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
quite some changes: # non-greedy memory allocation # generation of outputConstitutive to allow for script-based T16 extraction # exchange of phenomenological by more general phenopowerlaw # lattice is based on slip and twin families which can be treated as individual entities (switched on/off, separate hardening, etc.) # nicer debugging output # changed some error/warning codes # plus potentially some minor additional brushes here and there
2009-07-22 21:37:19 +05:30
!********************************************************************
! derive average stress and stiffness from constituent quantities
!********************************************************************
subroutine homogenization_averageStressAndItsTangent(&
ip, & ! integration point
el & ! element
)
use prec, only: pReal,pInt
use mesh, only: mesh_element
use material, only: homogenization_type, homogenization_maxNgrains
use crystallite, only: crystallite_P,crystallite_dPdF
openmp parallelization working again (at least for j2 and nonlocal constitutive model). In order to keep it like that, please follow these simple rules: DON'T use implicit array subscripts: example: real, dimension(3,3) :: A,B A(:,2) = B(:,1) <--- DON'T USE A(1:3,2) = B(1:3,1) <--- BETTER USE In many cases the use of explicit array subscripts is inevitable for parallelization. Additionally, it is an easy means to prevent memory leaks. Enclose all write statements with the following: !$OMP CRITICAL (write2out) <your write statement> !$OMP END CRITICAL (write2out) Whenever you change something in the code and are not sure if it affects parallelization and leads to nonconforming behavior, please ask me and/or Franz to check this.
2011-03-17 16:16:17 +05:30
use homogenization_RGC
quite some changes: # non-greedy memory allocation # generation of outputConstitutive to allow for script-based T16 extraction # exchange of phenomenological by more general phenopowerlaw # lattice is based on slip and twin families which can be treated as individual entities (switched on/off, separate hardening, etc.) # nicer debugging output # changed some error/warning codes # plus potentially some minor additional brushes here and there
2009-07-22 21:37:19 +05:30
use homogenization_isostrain
implicit none
integer(pInt), intent(in) :: ip,el
select case(homogenization_type(mesh_element(3,el)))
List of changes/modifications: * IO.f90 :: Adding error messages for RGC homogenization * crystallite.f90 :: Modifying convergent criteria in crystalline_updateState and crystalline_updateTemperature * material.f90 :: Adding IO_lc in homogenization_type(Name) * debug.f90 :: Adding debbugging statement and counter for material point loop * homogenization.f90 :: Adding homogenization_RGC blocks * homogenization_isostrain.f90 :: Modifying argument of homogenization_isostrain_stateInit * mpie_cpfem_marc.f90 :: Adding homogenization_RGC include * numerics.f90 :: Adding numerical parameters for RGC scheme * math.f90 :: Changing function name: math_permut to math_civita
2009-07-31 17:32:20 +05:30
!* isostrain
quite some changes: # non-greedy memory allocation # generation of outputConstitutive to allow for script-based T16 extraction # exchange of phenomenological by more general phenopowerlaw # lattice is based on slip and twin families which can be treated as individual entities (switched on/off, separate hardening, etc.) # nicer debugging output # changed some error/warning codes # plus potentially some minor additional brushes here and there
2009-07-22 21:37:19 +05:30
case (homogenization_isostrain_label)
openmp parallelization working again (at least for j2 and nonlocal constitutive model). In order to keep it like that, please follow these simple rules: DON'T use implicit array subscripts: example: real, dimension(3,3) :: A,B A(:,2) = B(:,1) <--- DON'T USE A(1:3,2) = B(1:3,1) <--- BETTER USE In many cases the use of explicit array subscripts is inevitable for parallelization. Additionally, it is an easy means to prevent memory leaks. Enclose all write statements with the following: !$OMP CRITICAL (write2out) <your write statement> !$OMP END CRITICAL (write2out) Whenever you change something in the code and are not sure if it affects parallelization and leads to nonconforming behavior, please ask me and/or Franz to check this.
2011-03-17 16:16:17 +05:30
call homogenization_isostrain_averageStressAndItsTangent(materialpoint_P(1:3,1:3,ip,el), &
materialpoint_dPdF(1:3,1:3,1:3,1:3,ip,el),&
crystallite_P(1:3,1:3,1:homogenization_maxNgrains,ip,el), &
crystallite_dPdF(1:3,1:3,1:3,1:3,1:homogenization_maxNgrains,ip,el), &
ip, &
el)
!* RGC homogenization
List of changes/modifications: * IO.f90 :: Adding error messages for RGC homogenization * crystallite.f90 :: Modifying convergent criteria in crystalline_updateState and crystalline_updateTemperature * material.f90 :: Adding IO_lc in homogenization_type(Name) * debug.f90 :: Adding debbugging statement and counter for material point loop * homogenization.f90 :: Adding homogenization_RGC blocks * homogenization_isostrain.f90 :: Modifying argument of homogenization_isostrain_stateInit * mpie_cpfem_marc.f90 :: Adding homogenization_RGC include * numerics.f90 :: Adding numerical parameters for RGC scheme * math.f90 :: Changing function name: math_permut to math_civita
2009-07-31 17:32:20 +05:30
case (homogenization_RGC_label)
openmp parallelization working again (at least for j2 and nonlocal constitutive model). In order to keep it like that, please follow these simple rules: DON'T use implicit array subscripts: example: real, dimension(3,3) :: A,B A(:,2) = B(:,1) <--- DON'T USE A(1:3,2) = B(1:3,1) <--- BETTER USE In many cases the use of explicit array subscripts is inevitable for parallelization. Additionally, it is an easy means to prevent memory leaks. Enclose all write statements with the following: !$OMP CRITICAL (write2out) <your write statement> !$OMP END CRITICAL (write2out) Whenever you change something in the code and are not sure if it affects parallelization and leads to nonconforming behavior, please ask me and/or Franz to check this.
2011-03-17 16:16:17 +05:30
call homogenization_RGC_averageStressAndItsTangent( materialpoint_P(1:3,1:3,ip,el), &
materialpoint_dPdF(1:3,1:3,1:3,1:3,ip,el),&
crystallite_P(1:3,1:3,1:homogenization_maxNgrains,ip,el), &
crystallite_dPdF(1:3,1:3,1:3,1:3,1:homogenization_maxNgrains,ip,el), &
List of changes/modifications: * IO.f90 :: Adding error messages for RGC homogenization * crystallite.f90 :: Modifying convergent criteria in crystalline_updateState and crystalline_updateTemperature * material.f90 :: Adding IO_lc in homogenization_type(Name) * debug.f90 :: Adding debbugging statement and counter for material point loop * homogenization.f90 :: Adding homogenization_RGC blocks * homogenization_isostrain.f90 :: Modifying argument of homogenization_isostrain_stateInit * mpie_cpfem_marc.f90 :: Adding homogenization_RGC include * numerics.f90 :: Adding numerical parameters for RGC scheme * math.f90 :: Changing function name: math_permut to math_civita
2009-07-31 17:32:20 +05:30
ip, &
el)
quite some changes: # non-greedy memory allocation # generation of outputConstitutive to allow for script-based T16 extraction # exchange of phenomenological by more general phenopowerlaw # lattice is based on slip and twin families which can be treated as individual entities (switched on/off, separate hardening, etc.) # nicer debugging output # changed some error/warning codes # plus potentially some minor additional brushes here and there
2009-07-22 21:37:19 +05:30
end select
return
endsubroutine
!********************************************************************
! derive average stress and stiffness from constituent quantities
!********************************************************************
subroutine homogenization_averageTemperature(&
ip, & ! integration point
el & ! element
)
use prec, only: pReal,pInt
use mesh, only: mesh_element
use material, only: homogenization_type, homogenization_maxNgrains
use crystallite, only: crystallite_Temperature
use homogenization_isostrain
openmp parallelization working again (at least for j2 and nonlocal constitutive model). In order to keep it like that, please follow these simple rules: DON'T use implicit array subscripts: example: real, dimension(3,3) :: A,B A(:,2) = B(:,1) <--- DON'T USE A(1:3,2) = B(1:3,1) <--- BETTER USE In many cases the use of explicit array subscripts is inevitable for parallelization. Additionally, it is an easy means to prevent memory leaks. Enclose all write statements with the following: !$OMP CRITICAL (write2out) <your write statement> !$OMP END CRITICAL (write2out) Whenever you change something in the code and are not sure if it affects parallelization and leads to nonconforming behavior, please ask me and/or Franz to check this.
2011-03-17 16:16:17 +05:30
use homogenization_RGC
quite some changes: # non-greedy memory allocation # generation of outputConstitutive to allow for script-based T16 extraction # exchange of phenomenological by more general phenopowerlaw # lattice is based on slip and twin families which can be treated as individual entities (switched on/off, separate hardening, etc.) # nicer debugging output # changed some error/warning codes # plus potentially some minor additional brushes here and there
2009-07-22 21:37:19 +05:30
implicit none
integer(pInt), intent(in) :: ip,el
select case(homogenization_type(mesh_element(3,el)))
List of changes/modifications: * IO.f90 :: Adding error messages for RGC homogenization * crystallite.f90 :: Modifying convergent criteria in crystalline_updateState and crystalline_updateTemperature * material.f90 :: Adding IO_lc in homogenization_type(Name) * debug.f90 :: Adding debbugging statement and counter for material point loop * homogenization.f90 :: Adding homogenization_RGC blocks * homogenization_isostrain.f90 :: Modifying argument of homogenization_isostrain_stateInit * mpie_cpfem_marc.f90 :: Adding homogenization_RGC include * numerics.f90 :: Adding numerical parameters for RGC scheme * math.f90 :: Changing function name: math_permut to math_civita
2009-07-31 17:32:20 +05:30
!* isostrain
quite some changes: # non-greedy memory allocation # generation of outputConstitutive to allow for script-based T16 extraction # exchange of phenomenological by more general phenopowerlaw # lattice is based on slip and twin families which can be treated as individual entities (switched on/off, separate hardening, etc.) # nicer debugging output # changed some error/warning codes # plus potentially some minor additional brushes here and there
2009-07-22 21:37:19 +05:30
case (homogenization_isostrain_label)
openmp parallelization working again (at least for j2 and nonlocal constitutive model). In order to keep it like that, please follow these simple rules: DON'T use implicit array subscripts: example: real, dimension(3,3) :: A,B A(:,2) = B(:,1) <--- DON'T USE A(1:3,2) = B(1:3,1) <--- BETTER USE In many cases the use of explicit array subscripts is inevitable for parallelization. Additionally, it is an easy means to prevent memory leaks. Enclose all write statements with the following: !$OMP CRITICAL (write2out) <your write statement> !$OMP END CRITICAL (write2out) Whenever you change something in the code and are not sure if it affects parallelization and leads to nonconforming behavior, please ask me and/or Franz to check this.
2011-03-17 16:16:17 +05:30
materialpoint_Temperature(ip,el) = &
homogenization_isostrain_averageTemperature(crystallite_Temperature(1:homogenization_maxNgrains,ip,el), ip, el)
!* RGC homogenization
List of changes/modifications: * IO.f90 :: Adding error messages for RGC homogenization * crystallite.f90 :: Modifying convergent criteria in crystalline_updateState and crystalline_updateTemperature * material.f90 :: Adding IO_lc in homogenization_type(Name) * debug.f90 :: Adding debbugging statement and counter for material point loop * homogenization.f90 :: Adding homogenization_RGC blocks * homogenization_isostrain.f90 :: Modifying argument of homogenization_isostrain_stateInit * mpie_cpfem_marc.f90 :: Adding homogenization_RGC include * numerics.f90 :: Adding numerical parameters for RGC scheme * math.f90 :: Changing function name: math_permut to math_civita
2009-07-31 17:32:20 +05:30
case (homogenization_RGC_label)
openmp parallelization working again (at least for j2 and nonlocal constitutive model). In order to keep it like that, please follow these simple rules: DON'T use implicit array subscripts: example: real, dimension(3,3) :: A,B A(:,2) = B(:,1) <--- DON'T USE A(1:3,2) = B(1:3,1) <--- BETTER USE In many cases the use of explicit array subscripts is inevitable for parallelization. Additionally, it is an easy means to prevent memory leaks. Enclose all write statements with the following: !$OMP CRITICAL (write2out) <your write statement> !$OMP END CRITICAL (write2out) Whenever you change something in the code and are not sure if it affects parallelization and leads to nonconforming behavior, please ask me and/or Franz to check this.
2011-03-17 16:16:17 +05:30
materialpoint_Temperature(ip,el) = &
homogenization_RGC_averageTemperature(crystallite_Temperature(1:homogenization_maxNgrains,ip,el), ip, el)
quite some changes: # non-greedy memory allocation # generation of outputConstitutive to allow for script-based T16 extraction # exchange of phenomenological by more general phenopowerlaw # lattice is based on slip and twin families which can be treated as individual entities (switched on/off, separate hardening, etc.) # nicer debugging output # changed some error/warning codes # plus potentially some minor additional brushes here and there
2009-07-22 21:37:19 +05:30
end select
return
endsubroutine
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
!********************************************************************
! return array of homogenization results for post file inclusion
! call only, if homogenization_sizePostResults(ip,el) > 0 !!
!********************************************************************
function homogenization_postResults(&
ip, & ! integration point
el & ! element
)
sorry, back to the previous version. grain deformation output is part of crystallite.f90, no longer done by homogenization. material.config reflects the changes.
2009-10-22 22:29:24 +05:30
use prec, only: pReal,pInt
use mesh, only: mesh_element
use material, only: homogenization_type
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
use homogenization_isostrain
openmp parallelization working again (at least for j2 and nonlocal constitutive model). In order to keep it like that, please follow these simple rules: DON'T use implicit array subscripts: example: real, dimension(3,3) :: A,B A(:,2) = B(:,1) <--- DON'T USE A(1:3,2) = B(1:3,1) <--- BETTER USE In many cases the use of explicit array subscripts is inevitable for parallelization. Additionally, it is an easy means to prevent memory leaks. Enclose all write statements with the following: !$OMP CRITICAL (write2out) <your write statement> !$OMP END CRITICAL (write2out) Whenever you change something in the code and are not sure if it affects parallelization and leads to nonconforming behavior, please ask me and/or Franz to check this.
2011-03-17 16:16:17 +05:30
use homogenization_RGC
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
implicit none
!* Definition of variables
integer(pInt), intent(in) :: ip,el
real(pReal), dimension(homogenization_sizePostResults(ip,el)) :: homogenization_postResults
homogenization_postResults = 0.0_pReal
select case (homogenization_type(mesh_element(3,el)))
List of changes/modifications: * IO.f90 :: Adding error messages for RGC homogenization * crystallite.f90 :: Modifying convergent criteria in crystalline_updateState and crystalline_updateTemperature * material.f90 :: Adding IO_lc in homogenization_type(Name) * debug.f90 :: Adding debbugging statement and counter for material point loop * homogenization.f90 :: Adding homogenization_RGC blocks * homogenization_isostrain.f90 :: Modifying argument of homogenization_isostrain_stateInit * mpie_cpfem_marc.f90 :: Adding homogenization_RGC include * numerics.f90 :: Adding numerical parameters for RGC scheme * math.f90 :: Changing function name: math_permut to math_civita
2009-07-31 17:32:20 +05:30
!* isostrain
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
case (homogenization_isostrain_label)
homogenization_postResults = homogenization_isostrain_postResults(homogenization_state(ip,el),ip,el)
openmp parallelization working again (at least for j2 and nonlocal constitutive model). In order to keep it like that, please follow these simple rules: DON'T use implicit array subscripts: example: real, dimension(3,3) :: A,B A(:,2) = B(:,1) <--- DON'T USE A(1:3,2) = B(1:3,1) <--- BETTER USE In many cases the use of explicit array subscripts is inevitable for parallelization. Additionally, it is an easy means to prevent memory leaks. Enclose all write statements with the following: !$OMP CRITICAL (write2out) <your write statement> !$OMP END CRITICAL (write2out) Whenever you change something in the code and are not sure if it affects parallelization and leads to nonconforming behavior, please ask me and/or Franz to check this.
2011-03-17 16:16:17 +05:30
!* RGC homogenization
List of changes/modifications: * IO.f90 :: Adding error messages for RGC homogenization * crystallite.f90 :: Modifying convergent criteria in crystalline_updateState and crystalline_updateTemperature * material.f90 :: Adding IO_lc in homogenization_type(Name) * debug.f90 :: Adding debbugging statement and counter for material point loop * homogenization.f90 :: Adding homogenization_RGC blocks * homogenization_isostrain.f90 :: Modifying argument of homogenization_isostrain_stateInit * mpie_cpfem_marc.f90 :: Adding homogenization_RGC include * numerics.f90 :: Adding numerical parameters for RGC scheme * math.f90 :: Changing function name: math_permut to math_civita
2009-07-31 17:32:20 +05:30
case (homogenization_RGC_label)
sorry, back to the previous version. grain deformation output is part of crystallite.f90, no longer done by homogenization. material.config reflects the changes.
2009-10-22 22:29:24 +05:30
homogenization_postResults = homogenization_RGC_postResults(homogenization_state(ip,el),ip,el)
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
end select
return
added a new module called numerics.f90 which reads in all numerical "parameters" from the file numerics.config (also being added). From now on this file has to be located in the working directory of the FEM-model and has to contain all necessary parameters.
2009-06-15 18:41:21 +05:30
endfunction
major restructuring of code. homogenization as well as constitutive are now free to choose. the runtime got somewhat longer (25% on simple tests) compared to a hardcoded isostrain homogenization. this might be a point of further optimization at a later stage... please use homogenization_isostrain.f90 as starting point / example for future developments of homog-schemes. the homogenization scheme now can additionally output certain results. hence, the userdata structure at each integration point now looks like this: - sizeHomogPostResults - block of that size containing homogPostResults then for each grain: - sizeGrainPostResults - block of that size containing crystallitePostResults, which consist of: + phaseID + volFrac + Eulers (3) + any constitutive post results requested
2009-05-07 21:57:36 +05:30
List of changes/modifications: * IO.f90 :: Adding error messages for RGC homogenization * crystallite.f90 :: Modifying convergent criteria in crystalline_updateState and crystalline_updateTemperature * material.f90 :: Adding IO_lc in homogenization_type(Name) * debug.f90 :: Adding debbugging statement and counter for material point loop * homogenization.f90 :: Adding homogenization_RGC blocks * homogenization_isostrain.f90 :: Modifying argument of homogenization_isostrain_stateInit * mpie_cpfem_marc.f90 :: Adding homogenization_RGC include * numerics.f90 :: Adding numerical parameters for RGC scheme * math.f90 :: Changing function name: math_permut to math_civita
2009-07-31 17:32:20 +05:30
END MODULE