Open aplowman opened 3 years ago
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: https://github.com/LightForm-group/damask-parse/issues/7#issue-860759161
Blocked by: https://github.com/LightForm-group/matflow/issues/104 We used a different method.
Requirements and aims
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]
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: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, themodify_volume_element
task will use both the existingvolume_element
and thevolume_element_response
to generate a newvolume_element.
The pertinent task inputs and outputs for iterationN
are as follows:generate_volume_element
(parameter-generating task)volume_element
simulate_volume_element_deformation
(parameter-consuming task)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
.volume_element_response
modify_volume_element
(parameter modifying task)volume_element
andvolume_element_response
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 tasksimulate_volume_element_deformation
gets its inputvolume_element
from the taskmodify_volume_element
. However, sincemodify_volume_element
also has an inputvolume_element_response
which must come from the tasksimulate_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: https://github.com/LightForm-group/matflow/issues/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
andvolume_element_response
and will output a newvolume_element
that has been modified to include the final orientation fromvolume_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 isnew_orientations
or similar.