New workflow for "multi-pass" rolling simulation in DAMASK

[aplowman]

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

1. generate_microstructure_seeds[method=random, software=damask]
2. generate_volume_element[method=random_voronoi, software=damask]
3. generate_load_case[method=uniaxial, software=formable]
4. simulate_volume_element_loading[method=CP_FFT, software=damask]
5. modify_volume_element[method=new_orientations, software=damask]

See: https://github.com/LightForm-group/UoM-CSF-matflow/blob/master/work_in_progress/multipass_rolling.yml

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:

1. generate_volume_element (parameter-generating task)

   • Outputs: volume_element

2. simulate_volume_element_deformation (parameter-consuming task)

   • Inputs: volume_element - originating from task generate_volume_element if current iteration is N=1, or from task modify_volume_element of iteration N-1 if current iteration is N>1.
   • Outputs: volume_element_response

3. modify_volume_element (parameter modifying task)

   • Inputs: volume_element and volume_element_response
   • Outputs: volume_element

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.

[mikesmic]

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.

[aplowman]

The changes required to MatFlow discussed above have been implemented in v0.2.17.

[Gbowker]

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

[aplowman]

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]
    ...

[Gbowker]

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)

[aplowman]

Blocked by: LightForm-group/matflow#104 We used a different method.