**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 (eg. *process mises, *process function, etc …)

• (ii) post-processors that generate one single map for the whole range of input cards (eg. *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 multiaxial 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