Synchronization of aramis time line with the control parameter

[rosoba]

The crack detection uses the notion of critical load represented by an index into the history of measured stages. There are currently two variables: one in AramisCDT.crack_detection_idx. in AramisData.evaluation_step_idx They were defined as properties derived from the index specifying the maximum force. However, this concept works only for tests with monotonic loading. In order to keep the library small and smart and flexible ... I suggest to introduce a parameter - crack_detection_step that must be specified by a client and completely outsource the notion of force or control parameter.

[kelidas]

I agree. Everything with relation to force will be removed. Crack_detection_step can be added, but crack_detection_step_idx leave or create evaluation_step in AramisData. How it works now:

• step numbers are obtained from file name (displ-Stage-0-3.npy) and they don't have to be continuous range (0,1,2,3 but 0,3,20) - idx has to be used to access data in arrays

New approach:

• the step numbers (stage numbers) used at this moment are not important for anybody (these numbers are useful only when I'm finding the same stage in program Aramis) - we can use continuous range(0, number of files),
• we will avoid to go from steps to idxs and vice versa,
• and instead of stage numbers we can use stage time (it is newly added to ad_channels.npy)

Conclusion:

• remove all force dependent tools
• remove idxs, use own step numbers and time to clearly identify stage

[kelidas]

This script (I'm using it to sync data) can be used to synchronize data from testing machine and data from Aramis

import numpy as np
from scipy.interpolate import interp1d

def synchronize_data(time, data, aramis_time, delta_time=0):
    ''' Synchronize time vs. data (e.g. force) with time of Aramis stages
    '''
    data_time = interp1d(time - delta_time, data, bounds_error=False, fill_value=0)
    return data_time(aramis_time)

Aramis 2D - delay of images is teor. 5 s but real is 5.1 s for every image. This means that the time of the last stages is moved (e.g. 4c V02 = 8 s). It can be seen in Figure bellow (left: histogram of error - most of errors are 0.1 s, middle: real delays vs teor dalay = 5 s, right: real vs. teor. time)

[rosoba]

The script in the module quaducom.devproc.bending_tensile_test.crack_strain_eval.py should identify the positions of the cracks and evaluate the effective crack bridge strain around the failure crack. The number of cracks determined by was 'crack_filter_avg': 4 On the other hand, the number of cracks determine via AramisCDT was 12.

[rosoba]

This has been fixed by kelidas - the problem was the norming in AramisBSA. Suggestion is to unify the BSA and CDT options. Another option would be to move the functionality on effective strains from experiment setup (BTT) to the specialized class in aramis package as planned originally. Should be discussed and decided next week.

[rosoba]

Another point related to this is the start time for the testing machine and aramis. Suggestion is to add another trait to AramisFieldData specifying the start_time. The particular value is then providet from the Instance of a particular test - containing also the other time dependent variables -- N(t) or M(t), etc.

[kelidas]

start_time added