Which parameters are independent for loading a microstructure?

[CsatiZoltan]

Hi,

In the configuration file, I need to give target_strain, read_bcs_from_file and strain_rate. I already ran a simulation successfully in which I imposed

...
target_strain 0.005 4 print_data
target_strain 0.010 4 print_data
target_strain 0.015 2 print_data
target_strain 0.020 2 print_data
...
read_bcs_from_file
...
strain_rate 1e-2

As the manual writes: "The velocities should be prescribed relative to the mesh dimensions and time-step size in order to produce expected strain rates.", I took into account the size of the specimen (0.15 mm), so I prescribed v=0.0015 mm/s at the selected nodes so as to replicate uniaxial tension. Everything went fine.

This time, I use externally defined boundary conditions (velocities) that come from DIC measurements. From our measurements, the target strain, the strain rate, and the nodal velocities are all given by the experiment. This leaves no free parameter to set. Hence, my question is: which quantities are fixed in FEPX and which ones are computed? In other words, how should I set the parameters to reconstruct the experimental setting? I tend to say that the velocities are definitely fixed by the experiment as we will perform an inverse analysis, in which velocities are Dirichlet boundary conditions.

Thank you,
Zoltan

[acmelab-ua]

@CsatiZoltan,

I'm a bit confused as to what you're doing. Are you attempting to apply velocities to all nodes within a polycrystal? Your domain is 3 dimensional, so how do you know the velocities at every point?

Boundary conditions are just that: essential velocities that are prescribed at the boundary of the domain. All other nodal velocities should be free to evolve according to the constitutive laws and evolution equations of the model. The boundary conditions should best match the macroscopic loading of your experiment.

So, let's assume you are doing the latter: you are applying boundary conditions on two parallel surfaces to mimic a uniaxial tensile experiment. Firstly, why do you need to apply boundary conditions from a file, when you could likely use one of the uniaxial boundary conditions to handle this?

To answer more directly: the strain rate and the nodal velocities are coupled. When you select built-in boundary conditions, you prescribe a strain rate. The nodal velocities are then calculated to adhere to the set strain rate (based on the size of the domain). When you supply your own boundary conditions, which contain velocities on a certain control surface, your strain rate should match that which would be calculated given the velocities in your boundary condition file.

I do not understand what you mean by there is no free parameter to set. Velocities and strain rates are coupled, and strain targets are set such that appropriate time steps are taken in the simulation to reach said targets.

Can you please better describe (perhaps with a sketch) what boundary conditions you are trying to apply?

[rquey]

@CsatiZoltan, I think you have to set the strain_rate from the average y velocities on the control surface (x1, and the length of the sample, along x). There is only one control surface/direction. As for the other velocities, the externally loaded velocities suffice (they are not related to target_strain and strain_rate).

@mkasemer, does it make sense?

[CsatiZoltan]

@rquey

I think you have to set the strain_rate from the average y velocities on the control surface (x1, and the length of the sample, along x).

That's what I thought too, to somehow trace this configuration back to a uniaxial loading case, but why the average y and not the average x velocities?

As for the other velocities, the externally loaded velocities suffice (they are not related to target_strain and strain_rate)

Thank you, this is a useful piece of information I did not know.

[rquey]

I think you have to set the strain_rate from the average y velocities on the control surface (x1, and the length of the sample, along x).

That's what I thought too, to somehow trace this configuration back to a uniaxial loading case, but why the average y and not the average x velocities?

If they don't average to zero, I think it would not be impossible to use the x velocities instead.

Let's wait and hear back from @mkasemer.

EDIT I've already done this, except that the imposed velocities were uniform on the surfaces and only normal.

[acmelab-ua]

@CsatiZoltan: so you are applying biaxial loading, then? Just to be clear? If truly uniaxial, you should be considering only one surface with non-zero velocities.

@rquey is right in his assessment that even for triaxial loading, there is only one control surface.

But, you still need to designate a strain rate. The internal calculation of time steps is based on the target strains and the strain rate.

[CsatiZoltan]

@acmelab-ua: The experiment was a uniaxial test, but locally the cropped part of the microstructure (300 x 300 pixel, see the first image I attached above) experiences heterogeneous velocity field. Therefore, if we apply such loading on the cropped part of the microstructure, that will be under general loading condition, not under uniaxial or multiaxial as far as these terms are defined in Section 2.1.2 of the documentation.

EDIT: @rquey :

I've already done this, except that the imposed velocities were uniform on the surfaces and only normal.

Yes, that's the difference between our case and what you have done before. I guess there is no confusion any more.

[mkasemer]

Yes, so I'm fairly sure that @rquey is right regarding the imposition of your strain rate (the average across the surface that you deem the control surface).

Though, I'm still not sure about how appropriate this setup is. I'm having a hard time seeing the significance in the polycrystal design and the applied "boundary conditions". It's essentially a pseudo-2D setup, and you already know all of the nodal velocities (and thus displacements). Why do you need complex simulations to calculate anything when it can be directly calculated (if you already know the velocity field)?

[acmelab-ua]

Yes, it was incorrect for me to state redundant. As stated previously, the internal time steps are calculated based on the strain rate and the target strains.

What you described makes sense. You must manipulate your above equation to see what is done internally:

time = target_strain / strain_rate

So, you prescribe the target strain and the strain rate. FEPX then calculates the time steps. If your strain rate is artificially high (i.e., it does not match the expected strain rate based on the velocities prescribed in your boundary conditions`, than the time step is going to be artificially low for the desired target strain. Your actual strain, then, will undershoot: if you have a small time step, it will reach a smaller strain than expected.

Does this make sense? It is, again, an issue with regard to the custom BCs (rarely used!) and must be better documented to remove the possibility of such error. It is difficult to apply a general fix for this: it is easy if we assume a cubic domain with constant velocities on a control face - FEPX could calculate the strain rate very easily internally, and the user would not have to specify it. However, it becomes an issue with specific domains, loadings, etc...

[CsatiZoltan]

@acmelab-ua

Does this make sense?

Yes, that is what I thought as well. Thank you for assuring me.

It is difficult to apply a general fix for this

Trial and error would suffice if I only had to consider one configuration. However, we have a series of measurements, so the idea is the following. Start with the first data set and compute the response with FEPX. Then perform a restart analysis to continue the loading of the body (now with different boundary conditions!). Since we have 382 steps to take, it must be automated. If nothing else works, I may try to write a predictor-corrector method, i.e.

1. For data step i, continue the restart analysis from data step i-1. Give the target strain for step i, being available from the load-displacement curve of the experiment.
2. Compute the strain rate based on the averaging strategy described above.
3. Perform the simulation with that candidate strain rate value (predictor).
4. If the target strain is not reached (or surpassed), go to step 2 (corrector).
5. Once the target stain for step i has been approximated to a given tolerance, accept the result and move to step i+1.

This will surely require tons of computations.

---

I already experienced, and you have just explained above, that when the specified strain rate is too large, the time step is too low to reach the given strain target. What happens when the strain rate is too small, and hence the time step is too large? Will FEPX stop when the target strain (displacement of the control surface divided by the initial length of the body) is reached, or it will overshoot? Knowing this information would help me in designing the predictor-corrector algorithm.

[acmelab-ua]

@CsatiZoltan: Do you mean that you will change the boundary conditions after every single load step, based on experimental data? If this is the intent, you will likely have to edit the code to handle this very specific case...

To be clear: when we restart a simulation, we load in the velocity field from the previous load step, saved to the restart output files. The simulation then continues with this velocity field and marches forward in time based on the additional load step(s). I'm not sure that it will re-consider the boundary conditions, and you may have to edit the code to allow for this custom functionality (I'm unsure without inspecting closely).

Then, your steps as described would be correct. I'm not sure you necessarily need step 4... if your strain rate is calculated correctly, and your target strain set, you will calculate the necessary time step correctly. Everything will then be in-sync with one another. The velocitiy * time on average will lead to displacements which will give you (again, on average) the macroscopic strain you desire. The computation for this work flow should not be terribly difficult - you will simply have to calculate the strain-rate based on the average. Everything else would, presumably, be able to be handled by FEPX.

You can check to see if FEPX reads in new boundary conditions properly upon restart by printing the velocity field at only the points BCs are set, i.e., VELOCITY(BCS), after the restart file has been parsed. I'm afraid that you will read in your custom BCs and velocities, but the velocity field will then be read-in, overwriting the essential velocities that were set when the BCs were read-in, and the simulation will continue with the previous essential velocities.

[CsatiZoltan]

Do you mean that you will change the boundary conditions after every single load step, based on experimental data?

Yes, that's exactly the goal. By load step, I do not mean strain or load increments, or multiple strain targets in the configuration file, rather a new analysis. E.g. the 4_restart example shipped with the FEPX code defines two analysis steps, cycle1 and cycle. In my case, I will have not 2, but 382.

I'm not sure you necessarily need step 4... if your strain rate is calculated correctly, and your target strain set, you will calculate the necessary time step correctly. Everything will then be in-sync with one another. The velocitiy * time on average will lead to displacements which will give you (again, on average)

For uniaxial loading (i.e. with boundary conditions defined in the FEPX manual), they will be in sync, but for the specific boundary conditions I apply, it may not be the case I think. Because for my non-proportional loading, there is no longer linear relationship. Anyway, I will try that.

I'm afraid that you will read in your custom BCs and velocities, but the velocity field will then be read-in, overwriting the essential velocities that were set when the BCs were read-in, and the simulation will continue with the previous essential velocities.

Hmmm... That is a problem. On the other hand, if I am not mistaken, FEPX performs the restart analysis using file input-output, and not in-memory. So I guess, I can programmatically modify the restart file with the new velocity BCs, without having to dig into the source code of FEPX and recompile it (that would be a pity, as I cannot program in Fortran).
In the meantime, I checked 4_restart, but that will not help me as in that example the boundary conditions stay the same for the two load steps:

boundary_conditions triaxial
loading_direction Z

[acmelab-ua]

The BCs are generally static (or iterated upon under very constrained and defined circumstances), so this would be a custom case that is not covered by the examples.

Yes, restart is performed using restart files that are written in binary format. The restart files could, ostensibly, be edited to change the essential velocities. I think it would be easier to handle in-code. Please email me at [email protected] if you'd like to discuss more about this.