**process cycle

Description

The cycle post processor may be used to apply the same post-processing operations on all cycles of a cyclic calculation. Typical application is to monitor the evolution of critical quantities (stress amplitude, mean stress, number of cycles to failure, etc…) from one cycle to the other.

This post-processor takes an arbitrary number of sub-processors as arguments. The output maps available in the results file that correspond to each cycle are automatically selected, and given as input to the embedded sub-processors. The definition of the time period of the cyclic calculation is used as a basis to sort out which maps do belong to a particular cycle.

A single map of post-processing results will be generated for each cycle detected in the sequence of output maps available in the input results files. In this context two types of embedded sub-processors may be distinguished:

• (i) post-processors that generate one map of results for each input map (e.g. *process mises, *process function, etc …)

• (ii) post-processors that generate one single map for the whole range of input cards (e.g. *process max, *process range, etc …, and all the damage post-processor in general)

Type (ii) needs no further specification, since the results given for each cycle correspond to a standard calculation on the associated cycle input maps (that may be selected by a repeated use of the **output_number command). On the opposite, for type (i) post-processors 2 options are available to specify if either the max of average value should be retained for each cycle.

Syntax

**process cycle \(~\,\) *period period [ *start tstart ] [ *end tend ] \(~\,\) *process proc1 [ typ1 ] [ sec1 ] \(~\,\) *process proc2 [ typ2 ] [ sec2 ] \(~\,\) … \(~\,\) *process procn [ typn ] [ secn ]

where period if the time period value of the cycle.

The *start command may be added if a preload sequence is stored in the results file, that needs to be skipped before scanning for cyclic results.

Similarly, the optional *end command will stop the scanning of cyclic results for maps whose time values are greater than the tend specified.

Embedded sub-processes are specified by an arbitrary number of *process commands. Argument proci is the name of the sub-process, and seci is the number of the input file section where the actual **process proci definition will be given. Default value for this section number is 2. For type (ii) post-processors (see description above) argument typ1 can be either max or average (default value is max).

Variables written in the post-processing files are the cycle number (variable cyc) and output variables associated to the various sub-processes. For the latter, the “_cyc” character string is appended to the conventional variable name.

Note

Specification of a material file is mandatory when using *process cycle, even if embedded sub-processors don’t need any material coefficients. In the latter case an empty material is required:

***post_processing_data
***return

Example

The following commands can be used to compute the max value of the von Mises stress invariant the mean value of the average stress, and the multi-axial stress amplitude for each cycle stored in the FE results files. The process format allows to store the result in an ASCII file: note the “_cyc” character string added to the name of the sub-process output variables.

% first section
****post_processing
  ...
  % note the need of an empty material file
  **material_file fake
  **process cycle
   *period 10.
   *process mises max 2
   *process trace average 2
   *process range 2
  **process format
   *list_var cyc sigmises_cyc sigii_cyc Dsig_cyc
   *file cycle.post
****return

% second section: sub processes definition
****post_processing
  **process mises
   *var sig
  **process trace
   *var sig
  **process range
   *var sig
****return

The *process fatigue_S should in theory be applied on the stabilized cycle. The next example illustrates how to use *process cycle to evaluate the influence of an incomplete material stabilization on the number of cycles to failure predicted by the fatigue_S model.

% first section
****post_processing
  ...
  **material_file fatigue_S_coefs
  **process cycle
   *period 50.
   *process fatigue_S
  **process format
   *list_var cyc NF_S_cyc
   *file nf_evolution.post
****return

% second section: sub processes definition
****post_processing
  **process fatigue_S
   *var sig
****return