New workflow for "multi-pass" rolling simulation in DAMASK
Opened this issue ยท 6 comments
Requirements and aims
- The aim is to simulate large strain rolling of sheet metal via a representative volume element using DAMASK
- Due to numerical issues, simulating rolling to a large strain is currently problematic in DAMASK
- To workaround this, we will mimic an experimental "multi-pass" rolling process, where a sheet metal is rolled multiple times and use this as a substitue for a single high-strain simulation
Minimal set of tasks
generate_microstructure_seeds[method=random, software=damask]
generate_volume_element[method=random_voronoi, software=damask]
generate_load_case[method=uniaxial, software=formable]
simulate_volume_element_loading[method=CP_FFT, software=damask]
modify_volume_element[method=new_orientations, software=damask]
Workflow features
The workflow will iterate on the volume_element
parameter. Initially tasks 1-5 will run; in subsequent iterations, tasks 4-5 will run with the output volume element from task 5 of the previous iteration. The final crystal orientations from the simulation task will be encoded into the new volume element for the next iteration. Additionally, the new volume element will be increasingly more squashed with each iteration, to represent a rolling pass.
Changes required - MatFlow core
Changes are required to MatFlow to support this workflow. These changes will be in relation to task dependency resolution within matflow.models.construction.py
. Consider the basic parameter-modifying task example workflow, which has the following tasks:
tasks:
# parameter_2 "generating" task:
- name: dummy_task_1
method: method_1
software: dummy_software
# parameter_2 "modifying" task:
- name: dummy_task_2c
method: method_1
software: dummy_software
base:
parameter_3: 301
# parameter_2 "consuming" task:
- name: dummy_task_2d
method: method_1
software: dummy_software
The new proposed workflow will also utilise, with respect to the volume_element
parameter, a parameter-generating task (generate_volume_element
), a parameter-consuming task (simulate_volume_element_deformation
) and a parameter-modifying task (modify_volume_element
). However, unlike in the simple example above, for the new case, the parameter-modifying task will need to be positioned at the end of the workflow. In particular, the modify_volume_element
task will use both the existing volume_element
and the volume_element_response
to generate a new volume_element.
The pertinent task inputs and outputs for iteration N
are as follows:
-
generate_volume_element
(parameter-generating task)- Outputs:
volume_element
- Outputs:
-
simulate_volume_element_deformation
(parameter-consuming task)- Inputs:
volume_element
- originating from taskgenerate_volume_element
if current iteration isN=1
, or from taskmodify_volume_element
of iterationN-1
if current iteration isN>1
. - Outputs:
volume_element_response
- Inputs:
-
modify_volume_element
(parameter modifying task)- Inputs:
volume_element
andvolume_element_response
- Outputs:
volume_element
- Inputs:
In the current version of MatFlow (v0.2.16), setting up a workflow like this results in an IncompatibleWorkflow
exception. This is because MatFlow currently always positions parameter-consuming tasks after parameter-modifying tasks, and so MatFlow determines that the task simulate_volume_element_deformation
gets its input volume_element
from the task modify_volume_element
. However, since modify_volume_element
also has an input volume_element_response
which must come from the task simulate_volume_element_deformation
, this leads to a circular dependency. Fixing this will require modifying this logic in a way that ensures compatibility with our existing iteration workflow, which we use for fitting crystal plasticity parameters.
Related issues: LightForm-group/matflow#81
Changes required - MatFlow extensions
An additional function mapper will be added to the matflow-damask
extension. The function mapper will take inputs: volume_element
and volume_element_response
and will output a new volume_element
that has been modified to include the final orientation from volume_element_response
and has been squashed.
Changes required - Task schemas and software definition files
A new task schema method will be added to the pre-existing modify_volume_element
task. A possible method name is new_orientations
or similar.
You can output orientations into the VE response by adding
- name: orientations
path: phase/1_IF_steel/generic/O
to the incremental data. This will output the orientation of every material point of the set phase. Let me know if you have a different output in mind and I'll add it when I finish changing around the output for a VE response.
The changes required to MatFlow discussed above have been implemented in v0.2.17.
workflow requires a definition:
old_orientations = workflow.tasks[3].elements[-1].outputs.volume_element_response['orientations']['data']['quaternions'][-1]
in matflow-damask/main.py
.
Note tasks[3]
works in the case that simulate_volume_element_loading
is in the 4th task position. Could this be referenced by name instead of number? Thanks
Hi Guy, you shouldn't need to access the workflow like that from within an extension. The input parameters (in this case volume_element_response
) will be passed to the function in matflow_damask.main
according to whatever parameters are specified in the task schema. Your new function in matflow_damask.main
has volume_element_response
in its signature (i.e. the bit after def
) doesn't it?
So something like:
def modify_volume_element(volume_element, volume_element_response):
...
old_orientations = volume_element_response['orientations']['data']['quaternions'][-1]
...
Hi, Ive been running into the issue invalid quaternion specified fromQuaternion
again. This I assume can only mean that quaternions written to the new material.yaml file in volume_element for a subsequent pass aren't to machine precision (>15d.p). I've checked the material.yaml file in element_2
and the quaternion components significant figures are inconsistent. Is it worth adding a line such as around(orientations, decimals=15)
I've added this to the input mapper modify_volume_element_new_orientations
, and this indeed prints the array if asked to to >15dp in the task output, but does not write it in the material.yaml file to this specification. @aplowman @mikesmic
Please see here fort my proposed change to damask-parse:
LightForm-group/damask-parse#7 (comment)
Blocked by: LightForm-group/matflow#104 We used a different method.