Zencrack is interfaced to Ansys/Mechanical APDL. Testing has been conducted up to and including Ansys 2024R1.

For Zencrack 7.7 to 9.3 there are two ways that the number of processors for Ansys jobs executed by Zencrack can be specified:

• Variable ZCR_OPTIONS_ANSYS in the zencrack.ini file (or OPTIONS_ANSYS for 7.7 and 7.8 in the runzcr script file) can be used to define parameters passed to the Ansys command line for all Zencrack jobs. The -np option can be added to this parameter. Refer to the file itself (located in the Zencrack tools folder) or the Installation And Execution Manual for more information about this variable.
• The command line option "-fe" can be used when executing a Zencrack job. This defines parameters to be passed to the Ansys command line for that particular Zencrack job. The parameters should be surrounded by quotes. For example, to use 4 processors:

  runzcrXX -j jobname -fe "-np 4"
  

  From version 7.9, this command line option can be used when a job is started from the "Run Zencrack" screen of the Zencrack GUI.

If the -np parameter is defined using both methods, the command line value takes precedence.

Note that from version 7.9-3 the Zencrack setup program requests information about the number of processors and configures the zencrack.ini file accordingly during the installation process.

The Ansys j-integral capability was added via the CINT option in Ansys 11.0. Interfacing to this capability is available from Zencrack version 7.5 and requires the service pack release Ansys 11.0SP1 (or later).

When including pressure load on the surfaces of brick or tet elements, Ansys Workbench generates the load via SURF154 elements. Such surfaces are updated if they are on target crack-block elements (from Zencrack 7.7-2) or on the remesh region (from Zencrack 9.1-1). However, contour integral evaluation in Ansys (up to at least v2024R1) does not support surface load applied via SURF154 elements. This leads to incorrect contour integral evaluation for any crack front node connected to a surface with pressure applied in this way. Since Zencrack only updates the surface without regard for the way in which that surface is used, this can cause incorrect contour integral evaluation without any warning being generated in the Zencrack .rep file. Note that Ansys will generate warnings in the .err and .out files that surface elements are not supported in contour integral evaluation, but will still carry out the contour integral evaluation and report potentially invalid results. Details of the warnings depend on the Ansys version. For example:

Version 14.5, 15.x, 16.x, 17.x, 18.x, 19.x, 2019.x, 2020.x, 2021.x, 2022.x, 2023.x, 2024.x:

*** WARNING ***                         CP =       1.342   TIME= 15:07:29
Fracture parameter calculation issue: Contour integration for crack 1
includes surface elements which are not supported.  These elements are
ignored, and the contour integration results may not be correctly
calculated.

Version 12.1 gives the second of the following warning types only, versions 13.0, 14.0 give both the following warning types:

*** WARNING ***                        CP =       0.796   TIME= 12:31:13
Error with CINT calculation: crack tip node attached to element type
that is not supported, Crack 1, crack tip node 549, element type 154.
Element will be ignored.

*** WARNING ***                        CP =       1.061   TIME= 12:31:14
Contour integration for crack 1 includes surface elements which are not
supported.  These elements are ignored, and the contour integration
results may not be correctly calculated.

As a workaround for this contour integral limitation there are two approaches:

• Allow the calculation of the contour integrals but do not use them for driving the analysis. Displacement based results can be used instead via: *ENERGY RELEASE RATE, PREDICTION=DISPLACEMENT
• Modify the uncracked mesh:
  • replace the SURF154 elements on the crack-blocks by TSHAP surface, and,
  • change the load application to direct load onto the target crack-blocks elements via SFE

Similar warnings are issued if contact elements or other invalid element types are detected in the contour integral region.

If an uncracked mesh uses geometry definitions and volume meshing (e.g. VMESH), it is possible that different versions of Ansys will produce slight differences in the resulting mesh e.g. different numbers of nodes and elements. Whether or not this will happen depends on the particular volumes being meshed and the Ansys versions.

In the context of a Zencrack crack-block analysis this has the implication that a valid Zencrack input and analysis which references a solid model uncracked mesh for one version of Ansys may generate errors in another version of Ansys because the underlying mesh is different (even though the uncracked model file is identical). The errors occur because the elements and node numbers used for crack-block definition are no longer valid in the "different" uncracked mesh that Ansys has generated. This is only a potential issue if:

• There is need to change Ansys versions part way through a project, or,
• A model is re-visited at a later date and re-run in a later version of Ansys.

As a workaround if this issue arises, it would be necessary to extract node and element definitions from the original uncracked model and create a new mesh-based uncracked model for use with the later version of Ansys.

When Zencrack uses tying to join two mesh regions and a boundary condition update is applied across one or more nodes included in the tying, there are overconstraints generated because nodes may be defined on a boundary condition and within a tie definition. These overconstraints are handled by the f.e. code during the solution phase and do not affect the validity of the solution. This situation may occur when boundary conditions are applied to mesh regions that include:

• for remeshing - the tie between rings and tet region or between tet region and surrounding mesh
• for crack-blocks - the tie between large crack-blocks and the surrounding mesh (depending upon how boundary conditions were defined in the uncracked mesh)

In Ansys 2024R1 the processing of overconstraints appears to have changed such that some models may give different solutions than previous Ansys versions (for identical input files). Observation across a range of models is that affected models will contain hot-spots of stress at the tying interface close to the region where boundary conditions are also applied.

An example is shown below for the supplied remeshing example model, ex02, which is a symmetry model for an embedded circular crack. The two stress plots are for identical input files of the cracked mesh. The stress plot in the tet region (with rings removed) for Ansys 2023R2 is the correct solution. The plot for Ansys 2024R1 shows clear hot-spots in the stress. If the overconstraints are removed, the Ansys 2024R1 solution reverts to that seen in Ansys 2023R2 (and earlier versions).

While this looks like a dramatic change of stress distribution, the effect in terms of a Zencrack growth prediction appears to be small, as demonstrated by the K vs a and a vs N plots for the first node on the crack front.

While this is further investigated we suggest that Ansys 2024R1 should be used with caution with Zencrack 9.3-1 (and earlier Zencrack versions).

Element type SOLID64 is fully removed in Ansys 2021R1 and reference to it produces an error in the Ansys .err file:

 *** ERROR ***                           CP =       0.469   TIME= 15:39:06
 An element referred to as 64 is a "null" or undefined element.
 

Any Zencrack pre-pass run will fail because the element extraction in the pre-pass run processes a list of element types that includes SOLID64. There is no workaround.

This also affects import of Ansys models to the Zencrack GUI if the RUN_ANSYS option in the zencrack_gui.ini is set to YES. A workaround is to set that option to NO.

The workaround if this arises when using Zencrack 8.3-1 (or earlier) : use Ansys 2020R2 (or earlier).

Some old keywords formats for SFE, N and EN input data us R5.0, R5.3 and R5.5 descriptors to indicate that the formats are from old Ansys versions. These descriptors have been replaced by a single value, UNBL, that did not exist in previous Ansys versions. This affects the ability of these options to be processed by Zencrack 8.3-1 (or earlier).

The workaround if this arises when using Zencrack 8.3-1 (or earlier): use Ansys 2020R2 (or earlier).

The CDWRITE option now produces output with modified format that did not exist in previous Ansys versions i.e. SFEBLOCK instead of SFE.

Any uncracked mesh generated by a CDWRITE command can potentially produce incorrect results because updates of SFEBLOCK are not carried out by Zencrack 8.3-1 (or earlier)

The workaround if this arises when using Zencrack 8.3-1 (or earlier): use Ansys 2020R1 (or earlier).

The Zencrack setup program for Zencrack 8.3-1 (and earlier) refers to Ansys version 2021R1 as version 21.1 (v211). The entry for ZCR_ANSYS_VER in the Zencrack .ini file should be 21.1 and the version reported in the .rep file will also be 21.1. However, the setup program does not correctly configure the Ansys version and executable name. The incorrect setup can be saved and the entry in the zencrack.ini file will be:

ZCR_ANSYS = C:\Program Files\ANSYS Inc\v211\ansys\bin\winx64\ansys21.exe
ZCR_ANSYS_VER = 2.1

The zencrack.ini file can be edited and the entry corrected to:

ZCR_ANSYS = C:\Program Files\ANSYS Inc\v211\ansys\bin\winx64\ansys211.exe
ZCR_ANSYS_VER = 21.1

The CDWRITE option now produces output with modified format that did not exist in previous Ansys versions i.e. BFBLOCK instead of BF.

Any uncracked mesh generated by a CDWRITE command can potentially produce incorrect results because updates of BFBLOCK are not carried out by Zencrack 8.3-1 (or earlier).

The workaround if this arises when using Zencrack 8.3-1 (or earlier) : use Ansys 2020R1 (or earlier) instead.

The Zencrack setup program for Zencrack 8.3-1 (and earlier) refers to Ansys version 2020R1 as version 20.1 (v201). The entry for ZCR_ANSYS_VER in the Zencrack .ini file should be 20.1 and the version reported in the .rep file will also be 20.1. However, the setup program does not correctly configure the Ansys version and executable name. The incorrect setup can be saved and the entry in the zencrack.ini file will be:

ZCR_ANSYS = C:\Program Files\ANSYS Inc\v201\ansys\bin\winx64\ansys20.exe
ZCR_ANSYS_VER = 2.0

The zencrack.ini file can be edited and the entry corrected to:

ZCR_ANSYS = C:\Program Files\ANSYS Inc\v201\ansys\bin\winx64\ansys201.exe
ZCR_ANSYS_VER = 20.1

In moving from Ansys 19.2 to Ansys 2019R1 the internal version number reported by Ansys has changed from 19.2 to 19.3. The Zencrack setup program for Zencrack 8.3-1 (and earlier) refers to version 2019R1 as version 19.3 (v193). The entry for ZCR_ANSYS_VER in the Zencrack .ini file should be 19.3 and the version reported in the .rep file will also be 19.3. For Ansys 2019R2 and Ansys 2019R3 the numbers are 19.4 and 19.5 respectively. The setup program should correctly identify and configure these version in the zencrack.ini file using the 19.3, 19.4 and 19.5 notation. For example:

ZCR_ANSYS = C:\Program Files\ANSYS Inc\v193\ansys\bin\winx64\ansys193.exe
ZCR_ANSYS_VER = 19.3

The issue described in this section is due to a changed Ansys behaviour related to the OUTRES option. From the Ansys 2019R1 release notes:

When Zencrack processes the results of an Ansys model, the nodal temperatures at the crack front nodes are extracted via a request for element-based temperatures (using *VGET with BFE, TEMP).

A request for element stresses via "OUTRES,STRS,ALL" in Ansys 19.2 or earlier would also have generated temperatures. Zencrack would correctly extract temperatures at the crack front nodes.

The meaning of the above change is that the request for element stresses via "OUTRES,STRS,ALL" in Ansys 2019R1 or later does not generate temperatures - a specific "OUTRES,ETMP,ALL" request is needed. If there are no temperatures available from the output requests the Ansys 2019R1 .out file will report that "The requested BFE data is not available". Zencrack will report all crack front temperatures as zero and calculate temperature dependent data from temperatures that are all zero.

For Ansys 2019R1 it is therefore necessary to ensure that an element temperature request exists in the uncracked mesh, whereas in earlier Ansys versions it was not necessary to explicitly request temperatures (as long as stresses were requested).

The issue described in this section is resolved in Zencrack 8.1-1.

When Zencrack processes an Ansys model there may be a requirement to run a "pre-pass" analysis with Ansys to extract information in a standardised format. Due to a change in the format of data written by the Ansys NWRITE command in version 18.0, Zencrack does not correctly process the output with the result that the analysis or read of a mesh into the GUI will fail.

For Zencrack versions up to and including 8.0-1 it is recommended to use Ansys versions up to and including 17.2 for full compatibility.

Ansys version 13 was released after Zencrack 7.6. Some changes in Ansys 13 mean that Zencrack 7.6 cannot be used with Ansys 13 (or later) on Windows machines. If Ansys 13 (or later) must be used on Windows machines, it is necessary to use Zencrack 7.7 (or later). There are also limitations on Linux machines if Zencrack 7.6 is used with Ansys 13 (or later). The reasons for the incompatibilities with version 7.6 and Ansys 13, along with the errors that can occur, are outlined below.

Errors executing Ansys (Windows only)

The Zencrack 7.6 setup configures Ansys to run an executable called ansys.exe. For example in the runzcr76.bat file:

set ZCRANSYS="C:\Program#Files\ANSYS#Inc\v130\ansys\bin\winx64\ansys.exe"

Using this Ansys executable in Ansys 13 (and later) gives an error which Ansys reports in a dialog box on the screen:

The program can't start because AnsMPI.dll is missing from your
computer. Try reinstalling the program to fix this problem.

The solution implemented in the version 7.7 setup program is to refer to a version specific executable in the runzcr .bat file. For example, ansys130.exe:

set ZCRANSYS="C:\Program#Files\ANSYS#Inc\v130\ansys\bin\winx64\ansys130.exe"

However, if this change is made manually in a Zencrack 7.6 installation with Ansys 13 (or later), a further error occurs. This is because the command line arguments being passed from Zencrack 7.6 to Ansys that were valid for the v12 ansys.exe are not valid for v13 ansys130.exe:

Invalid I/O redirection, please specify -i inputfile -o outputfile.

There is no workaround for this problem with the release version of Zencrack 7.6. So the Windows version of Zencrack 7.6 can only be used up to and including Ansys 12.

Invalid j-integral results (Linux only)

A change was made to j-integral output in Ansys 13 - the sign of all j-integral output was reversed compared to results obtained in earlier Ansys releases. So even though the Linux version of Zencrack 7.6 can execute Ansys 13, the resulting j-integral values are returned to Zencrack with an incorrect sign. In a crack growth analysis this will result in a message in the .rep file that there is no crack growth after the first finite element analysis.

The displacement based results (using *ENERGY RELEASE RATE, PREDICTION=DISPLACEMENT) are not affected by this issue.

Although displacement based results can be used, it is recommended that Zencrack 7.7 be used with Ansys 13 (or later) to prevent this issue from arising.