Zentech International Limited

Zentech International Limited
  Zencrack  
Home
Zentech
Engineering
Software
Downloads
Publications
Contacts

Overview
Technical
Sample applications
F.E. interfaces
Downloads
Purchase
Publications
Support
Contacts

Software > Zencrack > Support > Bug list > Full bug list

Full bug list


ZENCR384

Applies to: Version 7.6 documentation.

Fixed in development version: -

Fix included in release version: -

The following are noted with regard to the version 7.6 documentation:

  • Crack-block Library Manual, page 9 - crack-block l02_q3968x8 should be l02_q3968x16
  • Installation And Execution Manual, page 5 - the installation notes do not state that the installation is best carried out using the right-click "run as administrator" option for Windows Vista and Windows 7
  • User Subroutines Manual, page 21 - the header for this routine should read "SUBROUTINE user_prefea" and not "SUBROUTINE user_postfea"

ZENCR383

Applies to: Version 7.5 and later.

Fixed in development version: -

Fix included in release version: -

If the number of results sets saved from the f.e. analysis is greater than the number of load systems and the input contains a mixture of "search" load systems of type=maximum (or minimum),energy=search and regular load systems of type=constant amplitude (or static or spectrum), some arrays may not be allocated properly resulting in an invalid analysis. The analysis is likely to stop with an unexpected error. Mixing minimum or maximum search load systems with static, constant amplitude or spectrum load systems is not likely to occur in a practical analysis so this issue is unlikely to be encountered.

Workaround : Do not define minimum/maximum search load systems and static/constant amplitude/spectrum load systems in the same input file.


ZENCR382

Applies to: Version 7.1 and later.

Fixed in development version: 9 Mar 2010.

Fix included in release version: -

An error in a data check prevents use of the constant G integration scheme if there is temperature dependent crack growth data. The program incorrectly stops with error 2168.

Workaround : None.


ZENCR381

Applies to: All Windows versions up to and including v7.6.

Fixed in development version: 15 Dec 2009.

Fix included in release version: v7.6 downloads updated to include this fix on 22 Dec 2009.

The setup program for Windows versions of Zencrack does not allow installation on Windows 7 systems and instead reports an unidentified operating system.

Workaround : No workaround will be supplied for v7.5. Downloads have been updated for v7.6.


ZENCR380

Applies to: setupzcr75_xx (program date 20 Feb 2008 or later) and setupzcr76_xx (32 and 64 bit versions) (Windows only).

Fixed in development version: 15 Dec 2009.

Fix included in release version: v7.6 downloads updated to include this fix on 22 Dec 2009.

The setup program for Windows has two issues with Fortran 10 configuration:

  • if option (3) for Fortran 10.0 is used the configuration has the wrong path to the Fortran folder
  • input of option (4) for configuration with Intel Fortran version 10.1 is not permitted

Workaround : No workaround will be supplied for v7.5. Downloads have been updated for v7.6.


ZENCR379

Applies to: Process versions up to and including 7.18.

Fixed in development version: 8 Jun 2009.

Fix included in release version: -

The Process utility program does not extract results correctly if not all f.e. results sets are referenced by load systems.

Workaround : None.


ZENCR378

Applies to: Process versions up to and including 7.18.

Fixed in development version: 3 Jun 2009.

Fix included in release version: -

The Process utility program does not report correct values of the nodal G errors if they are in the range 1e-5< |error| <1e5.

Workaround : None.


ZENCR377

Applies to: Version 7.1 and later (Abaqus interface only).

Fixed in development version: 1 Dec 2009.

Fix included in release version: -

Contour integral results from the Abaqus analysis may not be extracted correctly if all the following conditions are met (some contour values will be zero in the .rep file but are non-zero in the Abaqus .dat file):

  • The option to extract results from the .fil file is used
  • There is more than one crack front in the model
  • Different crack fronts have different numbers of contours due to the use of different crack-block families

Workaround : Define the crack fronts in a specific order from those having lowest to those having highest number of contours.


ZENCR376

Applies to: Version 7.3e and later (Abaqus interface only).

Fixed in development version: 16 Jul 2009.

Fix included in release version: -

Error 3103 is intended to trap element sets with a GENERATE option that exceed 2000 data lines. But any element set exceeding 2000 data lines causes the error.

Workaround : Split the element set into blocks of <2000 data lines.


ZENCR375

Applies to: Version 7.1 and later.

Fixed in development version: 20 Mar 2009.

Fix included in release version: -

Combined time and fatigue integration produce erroneous results with the cycle count getting out of step with the integrated time if the fatigue spectrum contains only one cycle.

Workaround : None.


ZENCR374

Applies to: Versions 7.4 and 7.5 (Abaqus interface only).

Fixed in development version: 12 Feb 2009.

Fix included in release version: 7.6

If a data line in the *BOUNDARY section of the uncracked mesh contains only a node number or set name (without a comma or any other data) then an error is reported but the error message is not formatted correctly. The error should report that Zencrack requires the first degree of freedom field to be defined.

Workaround : Define the first degree of freedom.


ZENCR373

Applies to: Version 7.1 and later.

Fixed in development version: 6 Feb 2009.

Fix included in release version: 7.6

A power factor controls the step size for the first 10 steps of the error control scheme (see data line 2 of the *TOLERANCE keyword). If tolerances are met within all 10 of these steps the power factor should de-activate from step 11. But instead it is also applied in step 11. This results in a slightly bigger step size at step 11 than is expected. The overall analysis is valid but the step size control at step 11 is not as documented.

Workaround : None required.


ZENCR372

Applies to: Version 7.1 and later.

Fixed in development version: 22 Dec 2008.

Fix included in release version: 7.6

In some cases the user defined crack front option may generate a merge error between crack-blocks on opposite sides of the crack face reporting that too many or too few nodes have been merged between a pair of crack-blocks.

Workaround : None.


ZENCR371

Applies to: Version 7.1 and later.

Fixed in development version: 21 Aug 2008.

Fix included in release version: 7.6

If the top level folder name of the Zencrack installation is longer than 62 characters then an error will occur due to the program not being able to correctly access some files within the installation folders. The exact error depends upon the length of the folder name and the Zencrack version.

This does not affect the filename and path length for job files (which may be up to 256 characters).

Workaround : Ensure that the top level folder name is 62 characters or less. If the folder name is changed after running the tools\setupzcr program then the setup program will need to be re-run to update some configuration files.


ZENCR370

Applies to: Version 7.1 to 7.5-12 (Abaqus interface only).

Fixed in development version: 7 Jul 2008.

Fix included in release version: 7.5-13

If an element set name containing the sub-string "TYPE" is defined using the ELSET parameter on a *ELEMENT keyword line the following error may occur:

 ***ERROR 3051
 ELEMENT        X IS REPLACED BY CRACK-BLOCK   Y BUT ELEMENT        X
 IS NOT AN 8 OR 20 NODED ELEMENT.

Workaround : Change the element set name so that the string does not contain "TYPE" or make the TYPE= parameter the last option on the data line.


ZENCR369

Applies to: Version 7.1 and later.

Fixed in development version: no fix needed - the problem is related to poor midisde nodes in the uncracked mesh. See workarounds below.

If the initial crack is defined by the INITIAL=SIZE option it is possible that an error 4077 will be generated indicating inconsistent initial crack size data even though the input data is correct. This can happen if the replaced elements have midside nodes that are away from the proper midside positions. In such cases there will be warnings in the .rep file like the one shown below in workaround #2.

Workaround #1: Modify the midside node positions so that they are at the midsides.

Workaround #2: Modify the tolerance that determines whether a midside node is considered to be away from the midside position. This tolerance, TOLMIDWARN1, has a default value of 0.9. In the rep file you will see warnings like this one:

***WARNING
MIDSIDE NODE       95 BETWEEN CORNER NODES       99 AND       94
ON ELEMENT         10 WHICH IS REPLACED BY CRACK-BLOCK     3
IS AWAY FROM THE MIDSIDE POSITION:
DISTANCE CORNER NODE 1 - MIDSIDE =   3.473309E-01
DISTANCE MIDSIDE - CORNER NODE 2 =   2.781758E-01
RATIO (EXPECTED TO BE 1.0)       =       0.800896
THIS MAY AFFECT THE INITIAL CRACK SIZE AND ADVERSELY AFFECT ELEMENT DISTRIBUTIONS
IN THE CRACK-BLOCK. PLEASE CHECK YOUR INITIAL CRACKED MESH CAREFULLY.
YOU ARE ADVISED TO MOVE NODE      95 TO A BETTER MIDSIDE POSITION. A SUGGESTED POSITION IS:
 9.943850E+00  9.943850E+00  0.000000E+00
Determine the lowest ratio reported on all such warnings. Then set the tolerance TOLMIDWARN1 lower than this value. Alternatively just use a very low value for the tolerance e.g.:
*CONTROLS, TOLMIDWARN1=0.1


ZENCR368

Applies to: Version 7.4 to 7.5-12 (Finas interface only).

Fixed in development version: 9 Jun 2008.

Fix included in release version: 7.5-13

Some boundary condition data lines can be incorrectly formatted in the cracked mesh and cause a Finas error if all the following conditions are met:

  • The "from..to" method is used for boundary condition degrees of freedom
  • The crack-block(s) transfer to a new location
  • There are supports on the crack plane (i.e. symmetry in the crack plane) that need to be removed as the crack-blocks transfer.

Workaround: Re-write the affected data lines in the uncracked mesh with one degree of freedom per data line. For example replace:

BOUNDARY
    1     Step 0 Constraint Set
              1                   1    3
by
BOUNDARY
    1     Step 0 Constraint Set
              1                   1
              1                   2
              1                   3


ZENCR367

Applies to: Version 7.5 to 7.5-12.

Fixed in development version: 28 May 2008.

Fix included in release version: 7.5-13

The options on the SAVE keyword to save and re-number the .rst and .rth files from Ansys analyses during crack growth prediction do not save the files.

Workaround: None.


ZENCR366

Applies to: Versions 7.1 to 7.5-9.

Fixed in development version: 23 Apr 2008.

Fix included in release version: 7.5-10

In cases where the crack-block has several curved outer faces the mapping algorithms may fail with an error number 4095 or 4125 depending upon the mapping options used and whether or not temperature interpolation is required to generate the cracked mesh.

Workaround: None.


ZENCR365

Applies to: Version 7.4 and later.

Fixed in development version: 3 Dec 2008.

Fix included in release version: 7.6

The spline fixup option on keyword CRACK FRONT may produce a distorted mesh for step 2 of a growth analysis if the crack-blocks are of significantly unequal lengths along the initial crack front.

Workaround: None.


ZENCR364

Applies to: Versions 7.4 to 7.5-8.

Fixed in development version: 15 Apr 2008.

Fix included in release version: 7.5-9

The spline fixup option on keyword CRACK FRONT may produce distorted external shape to the crack-blocks if the crack-blocks are skewed significantly from the outer surface of a model. This may ultimately result in inside-out elements.

Workaround: None.


ZENCR363

Applies to: Versions 7.5 to 7.5-8.

Fixed in development version: 2 Apr 2008.

Fix included in release version: 7.5-9

The enhanced ring control mapping option may produce poorly distributed elements in the crack-blocks after a reasonable amount of non-planar growth. The elements are biased too far from the crack plane and may ultimately produce an inside-out element error.

Workaround: None.


ZENCR362

Applies to: Versions 7.4 to 7.5-8.

Fixed in development version: 9 Apr 2008.

Fix included in release version: 7.5-9

A model containing 8 noded brick elements and using multiple nodes at each crack front nodal position does not generate a valid cracked mesh after the first crack-block transfer when *BOUNDARY SHIFT, TYPE=TRANSFER is activated.

Workaround: None.


ZENCR361

Applies to: Version 7.5-8 (Windows 32bit version only).

Fixed in development version: 7 Apr 2008.

Fix included in release version: 7.5-9

A model containing 8 noded brick elements and using multiple nodes at each crack front nodal position does not generate a valid cracked mesh.

Workaround: None.


ZENCR360

Applies to: Versions 7.5-2 to 7.5-8.

Fixed in development version: 4 Apr 2008.

Fix included in release version: Process v7.16

The data for columns "error node" and "error largest" is not extracted correctly by version 7.15 of the PROCESS post-processor for .rep files generated by Zencrack 7.5-2 or later. Instead the two relevant columns in the .csv file contain zeros or a Fortran error will occur and no .csv file will be created.

Workaround: None.


ZENCR359

Applies to: Versions 7.0 to 7.5-8 (Windows only).

Fixed in development version: 22 Dec 2008.

Fix included in release version: 7.6

A linker error occurs when using a Zencrack user subroutine if the Zencrack top level folder name contains any spaces.

Workaround: Edit the runzcr7x.bat file in the tools folder and change all occurences of the string:

%ZCROBJ% %ZCRLIB%
to:
"%ZCROBJ%" "%ZCRLIB%"
In addition for v7.5-8 change all occurences of the string:
%ZENDIR%\bin\rlmclient.lib
to:
"%ZENDIR%\bin\rlmclient.lib"


ZENCR358

Applies to: Versions 7.0 to 7.5 (Windows only).

Fixed in development version: 19 Feb 2008.

Fix included in release version: 7.5-8

A linker error occurs when using a Zencrack user subroutine if the Visual Studio environment is VS2005.

Workaround: Contact Zentech.


ZENCR357

Applies to: Versions 7.4 to 7.5 (Finas interface only).

Fixed in development version: 7 Feb 2008.

Fix included in release version: 7.5-7

If more than two sets of temperatues are defined in the model then the second and subsequent sets are not processed correctly for interpolation into the crack-blocks.

Workaround: None.


ZENCR356

Applies to: Versions 7.1 to 7.5.

Fixed in development version: 21 Dec 2007.

Fix included in release version: 7.5-7

If boundary shifting is on in a crack growth analysis the crack-blocks may rotate in the opposite direction to the way the crack is growing. This is likely to result in the analysis failing with distorted elements.

Workaround: This is most likely to occur if absolute coordinate values are small e.g. units are metres. If this is the case change to mm units.


ZENCR355

Applies to: Versions 7.0 to 7.5 (Abaqus interface only).

Fixed in development version: 4 Dec 2007.

Fix included in release version: 7.5-7

If user subroutines zcr-jint or zcr-ctint are used to extract results from the Abaqus .fil file and a step has more than 100 increments the data cannot be processed by Zencrack.

Workaround: Extract results from the .dat file.


ZENCR354

Applies to: Versions 7.0 to 7.5.

Fixed in development version: 6 Nov 2007.

Fix included in release version: 7.5-6

When more than 80 load systems are defined there are some incorrectly initialised arrays. Subsequent lookups during crack growth integration return invalid data resulting in an error e.g. Error 6018.

Workaround: None.


ZENCR353

Applies to: Versions 7.5.

Fixed in development version: 31 Oct 2007.

Fix included in release version: 7.5-6

When the fix for zencr345 was done the value of NUMBERcfnodes was changed to include all crack front nodes, not just corner nodes as stated in the documentation. The code is now changed to be consistent with the v7.5 documentation in which NUMBERcfnodes is the number of corner nodes on the crack front. This affected all user subroutines which have NUMBERcfnodes in the argument list.

Workaround: None.


ZENCR352

Applies to: Versions 7.1 to 7.5.

Fixed in development version: 30 Oct 2007.

Fix included in release version: 7.5-6

The second node in a split pair may not be placed correctly onto the curved outer surface of the element when boundary shift is on and relax and surround fix are off. The problem occurs for the midside node in the element next to the crack-block i.e. the midside node affected by a boundary shift.

Workaround: None.


ZENCR351

Applies to: Versions 7.1 to 7.5.

Fixed in development version: 19 Oct 2007.

Fix included in release version: 7.5-4

In an analysis using Abaqus or Ansys with multiple results sets at different temperatures the internal cross referencing of temperature values used during crack growth integration is incorrect. The temperature is always derived from the final results set rather than the results set being used to drive the integration. If, and only if, there are temperature dependent material properties this will affect the result of the integration. In most cases the effect is considered likely to be small. Only the crack growth integration is affected - the processing of individual results sets and the report of G, K, E and nu values for each result set is correct.

Workaround: None.


ZENCR350

Applies to: Version 7.5.

Fixed in development version: 21 Sep 2007.

Fix included in release version: 7.5-2

The maximum or minimum displacement-based Ki, Kii and Kiii reported in the search table summary in the .rep file are only valid if the analysis is using displacement-based results to drive the crack growth. If energy values are used to drive the growth the K values reported in the search table are their initialisation values of 0 or 1e20 - the analysis itself is correct only the Ks in the search output table are incorrect.

Workaround: None.


ZENCR349

Applies to: Versions 7.1 to 7.5.

Fixed in development version: 10 Sep 2007.

Fix included in release version: 7.5-1

In some circumstances a time dependent or combined time-fatigue crack growth analysis may hang during crack growth integration. If the option *OUTPUT, PROGRESS=YES is used the last message output to the screen is:

Starting crack growth integration
Integrating crack front 1, node 1 : pass 1

Workaround: None.


ZENCR348

Applies to: Version 7.4a and later (Abaqus interface only).

Fixed in development version: 1 Dec 2009.

Fix included in release version: -

Zencrack will report error 5020 "end of file found unexpectedly while trying to read temperature data" when a job meets the following criteria:

  • there are temperatures in the finite element analysis
  • the model has more than one crack front
  • results are extracted from the Abaqus .fil file using subroutine zcr-jint or zcr-ctint

Workaround: Extract results from the .dat file instead or contact Zentech for a modified user subroutine that fixes the problem.


ZENCR347

Applies to: 3dmesh utility program version 7.06 (released with Zencrack 7.5).

Fixed in development version: 26 Feb 2008.

Fix included in release version: 7.5-8

When a Finas output file is requested the program appears to hang after issuing the report "Processing XX crack front positions".

Workaround: At the point where the program hangs it is waiting for input that has no meaning for a Finas output file. Enter a 2 and the program will continue normally.


ZENCR346

Applies to: Version 7.1 to 7.5 (Unix and Linux only).

Fixed in development version: 19 Feb 2008.

Fix included in release version: 7.5-8

If an existing Zencrack executable is used the command line -e option requires a "./" in front of the executable name. This is not documented in the manuals or the runzcr75 script file. e.g.

runzcr75 -j jobname -e ./my_saved_exe.exe


ZENCR345

Applies to: Version 7.1 to 7.4a.

Fixed in development version: 11 May 2007.

Fix included in release version: 7.5

The node number and coordinate data passed into crack growth user subroutines is incorrect for models consisting of 8 noded bricks. These are secondary variables passed into the routine for information and are not usually critical. The value of da/dn is handled correctly provided it is not a function of any of these secondary variables.

Workaround: Use 20 noded bricks.


ZENCR344

Applies to: Version 7.0 to 7.4a.

Fixed in development version: 13 Apr 2007.

Fix included in release version: 7.5

The calculation of displacement based SIFs may not be accurate for models that have 8 noded bricks and a curved crack front due to a poor estimate of the distance from a crack face node to the crack front.

Workaround: Use 20 noded bricks.


ZENCR343

Applies to: Version 7.4, 7.4a (Marc interface only).

Fixed in development version: 12 Apr 2007.

Fix included in release version: 7.5

The field width of temperatures output after processing a temperature option is too wide and the temperatures may subsequently be incorrectly read by Marc when analysing the cracked mesh.

Workaround: None.


ZENCR342

Applies to: Version 7.4, 7.4a (Marc interface only).

Fixed in development version: 11 Apr 2007.

Fix included in release version: 7.5

Processing of data from Marc data blocks is not correct for the following cases and could cause incorrect results or the job to fail:

  • reading the first data line of DISP CHANGE or TEMP CHANGE
  • processing multiple alphnumeric data lines for temperature, fixed displacement and loading updates
  • fixed format displacements which fill their field width.

Workaround: None.


ZENCR341

Applies to: Version 7.4, 7.4a (Marc interface only).

Fixed in development version: 3 Apr 2007.

Fix included in release version: 7.5

An array allocation error will occur if Zencrack processes a temperature definition block in which a node set is used rather than a node list.

Workaround: Use a node list rather than a node set.


ZENCR340

Applies to: Version 7.4, 7.4a - Utility program PROCESS.

Fixed in development version: 12 Feb 2007.

Fix included in release version: 7.5

For a time dependent growth analysis or a combined time-fatigue growth analysis the data for the time column (column H) is not read correctly and is always output as zero.

Workaround: None.


ZENCR339

Applies to: Version 7.0 to 7.4a.

Fixed in development version: 11 Jan 2007.

Fix included in release version: 7.5

In a model with multiple crack fronts the determination of whether or not a crack front is allowed to transfer could be incorrect if:

  • at least one crack front exists that contains only through crack-blocks, and,
  • at least one crack front exists that contains one or more quarter circular crack-blocks.

Workaround: Define all crack fronts that contain only through crack-blocks before any crack fronts that contain quarter circular crack-blocks.


ZENCR338

Applies to: Version 7.4, 7.4a (Finas interface only).

Fixed in development version: 11 Jan 2007.

Fix included in release version: 7.5

Connectivity output is incorrectly written for split elements when the wide data format is used.

Workaround: Use the narrow data format.


ZENCR337

Applies to: Version 7.0 to 7.4a.

Fixed in development version: 3 Jan 2007.

Fix included in release version: 7.5

In some limited cases the numerical integration scheme can get stuck in an infinite loop. The program appears to hang at the command prompt.

Workaround: None.


ZENCR336

Applies to: Version 7.4, 7.4a.

Fixed in development version: 14 Dec 2006.

Fix included in release version: 7.5

If a large number of nodes are listed on a boundary constraint option in the uncracked mesh the update is done correctly but can take an unexpectedly long elapsed time.

Workaround: None.


ZENCR335

Applies to: Version 7.4 (Abaqus and Marc interfaces).

Fixed in development version: 14 Dec 2006.

Fix included in release version: 7.5

If an existing deltau.val output file is set read-only any job run in the same directory stops with a Fortran error when the first attempt is made to use the deltau.val file. The deltau.val file can exist for the Marc interface or the Abaqus interface (only when results are extracted from the Abaqus .fil file).

Workaround: Turn off the read-only attribute for the file.


ZENCR334

Applies to: Version 7.4, 7.4a.

Fixed in development version: 20 Sep 2006.

Fix included in release version: 7.5

The values of the parameters FIRST and STEP are not read correctly for the TYPE=FROM REMOTE option on the REMOTE TRANSFER keyword. Regardless of the input both parameter values are set to 1.

Workaround: None.


ZENCR333

Applies to: Version 7.4.

Fixed in development version: 28 Jul 2006.

Fix included in release version: 7.4a

If there are multiple crack-blocks along a crack front the program may not correctly identify the intersection points of the user defined crack front and the crack-block edges. This can result in an error reported during the mapping process.

Workaround: Reversing the order of points on the user defined crack front may solve the problem in some cases.


ZENCR332

Applies to: Version 7.4 - Utility program PROCESS.

Fixed in development version: 27 Jul 2006.

Fix included in release version: 7.4a

Raw contour values reported by utility program PROCESS are all zero in v7.4 (i.e. the contents of columns BC onwards).

Workaround: Edit the .rep file and change header text on tables listing the raw contour integral values in the rep file from:

CRACK    SET  NODE      CONTOUR  1
to:
CRACK    SET  NODE      CONTOUR 1


ZENCR331

Applies to: Version 7.3 to 7.4.

Fixed in development version: 4 Jul 2006.

Fix included in release version: 7.4a

The error control scheme does control step sizes between f.e. analyses correctly if results sets exist that are not used in load systems. The error can be reported as outside the tolerance value when it isn't. Even if the error is reported as inside the tolerance, the step size is not calculated correctly. For example:

 LARGEST ERROR ON G FOR THIS STEP IS         0.078796%	[definitely < 5% !!]
 LARGEST ERROR ON G SO FAR IS               -4.793779%
 AVERAGE ERROR ON G SO FAR IS               -0.061326%
 NUMBER OF ERROR EVALUATIONS                    5

 ERROR IS OUTSIDE THE TOLERANCE VALUE OF     5.000000% (75.0% OF TOLERANCE USED FOR THIS CHECK)
 SCALE FACTOR ON da FOR NEXT STEP IS         9.98424E-01

Workaround: For the Abaqus interface a workaround is to use the STEPS option on *ENERGY RELEASE RATE to turn off j-integral requests for all steps except the ones referenced in load systems. Otherwise, use the adaptive or fixed schemes on *TOLERANCE.


ZENCR330

Applies to: Version 7.1 to 7.4.

Fixed in development version: 4 Jul 2006.

Fix included in release version: 7.4a

Possible Fortran error when using a user defined crack front. The error occurs in a mapping routine because the internally calculated crack-block edge ratio values are incorrect. This is due to incorrect calculation of the points where the user defined crack front intersects the crack-block edges.

Workaround: Try reversing the order of the spline points in the input file.


ZENCR329

Applies to: Version 7.0 to 7.4.

Fixed in development version: 4 Jul 2006.

Fix included in release version: 7.4a

If existing output files are set read-only and the job is re-run using the overwrite=yes option, the existing files cannot be deleted and Zencrack stops with a Fortran error when the first attempt is made to use one of the existing files.

Workaround: Turn off the read-only attribute for the files.


ZENCR328

Applies to: Version 7.1 to 7.4.

Fixed in development version: 4 Jul 2006.

Fix included in release version: 7.4a

The value of constraint set by the user in user subroutine user_constraint is not assigned to the internal variable in the calling routine.

Workaround: None.


ZENCR327

Applies to: Version 7.4 (Abaqus interface only).

Fixed in development version: 6 Jun 2006.

Fix included in release version: 7.4a

Surface update on all faces of an element number or element set name on the Abaqus *SURFACE option (i.e. data specified without any face id) causes an array bounds error at line 160 of surfabq if the data line has no comma.

Workaround: Add a comma after the element number or set name.


ZENCR326

Applies to: Version 7.3 to 7.4 - Utility program PROCESS.

Fixed in development version: 27 Jul 2006.

Fix included in release version: 7.4a

Utility program PROCESS searches the rep file for table headings. If any of these headings were included as part of commented data on a '#' line in the zcr file, the process program fails with a fortran error.

Workaround: Locate the "echo of zcr file" section in the rep file and remove any comment lines that include table headings from a rep file. There is no need to re-run the Zencrack analysis.


ZENCR325

Applies to: Version 7.1 to 7.4 (Ansys interface only).

Fixed in development version: 10 May 2006.

Fix included in release version: 7.4a

Zencrack job fails with a Fortran error in greadansys after the first Ansys analysis. This is due to the coordinate fields in the .001 output file from Ansys merging into one another as a result of very large coordinates ( >9999999 or <-999999).

Workaround: Modify the unit system so that the coordinate values are smaller than abs(999999).


ZENCR324

Applies to: Version 7.1 to 7.4 (Marc interface only).

Fixed in development version: 3 May 2006.

Fix included in release version: 7.4a

Energy based results for an embedded crack (i.e. a crack front which forms a closed loop) are incorrect.

Workaround: Use *ENERGY RELEASE RATE, PREDICTION=DISPLACEMENT.


ZENCR323

Applies to: Version 7.3 to 7.4.

Fixed in development version: 20 Apr 2006.

Fix included in release version: 7.4a

Extrapolation of displacement based results to the crack front nodes may be slightly incorrect for some models with only one element along the crack front. Ks are likely to be out by less than 1% if there is a problem.

Workaround: None.


ZENCR322

Applies to: Version 7.4.

Fixed in development version: 10 Feb 2006.

Fix included in release version: 7.4a

The description in the user manual of the variable IFLIPSTATUS in the argument list of user subroutine user_transfercf is inconsistent with what is done in Zencrack 7.4. In version 7.4 the value of this variable must be set to greater than [0.5 x number of crack-blocks along the crack front] if transfer is required and not to 1 as indicated in the manual.

Workaround: Set the return value of IFLIPSTATUS to 0 for "no transfer" or a high number if transfer is required (e.g. 1000).


ZENCR321

Applies to: Version 7.4 (Abaqus interface only).

Fixed in development version: 19 Dec 2005.

Fix included in release version: 7.4a

The request for output of K FACTORS from an Abaqus analysis causes j-integral data to be read incorrectly if all of the following conditions are met:

  • There is more than 1 crack front in the model.
  • There are multiple sets of j-integral results data (i.e. multiple load steps or multiple increment output within one step in the f.e. analysis).
  • Results data is requested from the .fil file using the zcr-jint subroutine.

Workaround:

  • Remove the request for K FACTORS ouput, or,
  • Extract results from the .dat file.

ZENCR320

Applies to: Version 7.0 to 7.4 (Abaqus interface only).

Fixed in development version: 25 Nov 2005.

Fix included in release version: 7.4a

Please see the note "Using Zencrack with Abaqus 6.5-4 (or later)" on the Abaqus interface support page for information on this item.


ZENCR319

Applies to: Version 7.1 to 7.4.

Fixed in development version: 2 Nov 2005.

Fix included in release version: 7.4a

The program may fail with an error 4034 when a user defined initial crack front is used. This can occur if there is more than 1 crack-block along the crack front and the crack-blocks are distorted to be long and thin in the crack plane (e.g. 10:1).

Workaround: None.


ZENCR318

Applies to: Version 7.1 to 7.4.

Fixed in development version: 11 Nov 2005.

Fix included in release version: 7.4a

If the *CRACK FRONT, INITIAL=POINTS option is used to define the initial crack front the program will stop unnecessarily with error 4077 under two conditions:

  • if the user enters values for ratio or size in fields 4 and 5 of data line 2 for the crack-blocks and the values are inconsistent between adjacent crack-blocks
  • if there is a mixture of normal and reversed crack-blocks on the crack front and no data is entered in fields 4 and 5.

Workaround: When using INITIAL=POINTS for a crack front definition, ensure that all data items in fields 4 and 5 for the crack-blocks are consistent. Since these values are not used by the analysis, any suitable values can be defined that will pass the data check. The simplest approach that will work in all cases is to use 0.5 for both fields for all crack-blocks.


ZENCR317

Applies to: Version 7.0 to 7.4.

Fixed in development version: 4 Nov 2005.

Fix included in release version: 7.4a

A certain configuration of one normal and one reversed quarter circular crack-block is not identified as being on the same crack front. This occurs if the orientations are such that a 1-4 edge on one crack-block is adjacent to a 1-4 edge on another crack-block. The program stops with errors 4107 and 4108. (The 1-4 edge is the "edge 2" described in the user manual figure "Definition of nodes for crack orientation").

Workaround: None.


ZENCR316

Applies to: Version 7.4.

Fixed in development version: 18 Oct 2005.

Fix included in release version: 7.4a

The option on *MAPPING to activate biasing of nodes within the crack front element rings may cause a run-time error if:

  • there is more than one crack-block along a crack front, or,
  • both sides of a crack are modelled.
The error occurs only in a growth analysis. The program fails during generation of the second f.e. mesh (the first mesh is correct). If boundary transfer is on and there is transfer after the first f.e. analysis, the error occurs after completion of the first f.e. analysis for which there was no transfer.

Workaround: Turn off biasing or use Zencrack 7.3.


ZENCR315

Applies to: User manual for version 7.0 to 7.4.

Fixed in development version: 27 Jul 2006.

Fix included in release version: User Manual Issue 7.4 Revision 1 (released with Zencrack 7.4a)

The option *MAPPING, NORMAL=YES / NO is not documented correctly. It is correctly stated that the option applies only to quarter circular crack-blocks when *MAPPING, TYPE=TWO STAGE is used. However, the documentation incorrectly implies that the option will give element edges normal to the crack front in the final mesh. The correct description is as follows:

The option NORMAL=YES activates an additional modification during the intermediate part of the two stage mapping algorithm. In this intermediate part of the mapping process, the unit cube crack-block is modified to contain an ellipse of the correct A and B ratio. If NORMAL=YES is used, the element edges within the controlled element rings are modified to be normal to the crack front. For highly elliptic cracks, or cases where the controlled ring size is large, this may lead to nodes falling outside the crack-block unit cube boundary. The program then reports a warning and reverts to NORMAL=NO for the affected crack-block e.g.:

***WARNING
It is not possible to generate element edges normal to the crack front for crack-block 2.
Mapping for this crack-block will be re-attempted with NORMAL=NO.

The unit cube nodal positions are then mapped into the crack-block "real space". If the crack-plane of the target element is square then the element edges should be close to being normal to the crack front. If, however, the crack plane is distorted or rectangular, the element edges will not be normal to the crack front. Even if the final mesh does not contain element edges that are nowmal to the crack front, it will, in most cases, be better than the mesh obtained by NORMAL=NO.


ZENCR314

Applies to: Version 7.1 to 7.4.

Fixed in development version: 12 Sep 2005.

Fix included in release version: 7.4a

An analysis with quarter-circular crack-block(s) may end with error 4027 if the option *MAPPING, NORMAL=YES is used (note: this is a default option if parameter NORMAL is omitted):

***ERROR 4027
VALUE OF THETA FOR NODE 8332 (INTERNAL NODE 8332) LIES OUTSIDE
THETA RANGE OF CRACK FRONT NODES FOR CRACK-BLOCK 1:
THETA= -8.71667281E-03
THETA RANGE = -1.57079633E-12 TO 1.57079633E+00

Additional information with the error message suggests setting TOLMAPEND on the *CONTROLS keyword. This may allow a mesh to be generated but it may contain some distortion within the crack-blocks. If there are multiple crack-blocks on a crack front, some may be mapped using NORMAL=NO and others using NORMAL=YES. The result may be different looking meshing within the crack-blocks as different mapping options have been used.

Workaround: None.


ZENCR313

Applies to: Version 7.0 to 7.3f.

Fixed in development version: 9 Aug 2005.

Fix included in release version: 7.4

If the number of cycles in an individual load system or the total spectrum exceeds 2147483647, then the program fails with an integer overflow.


ZENCR312

Applies to: Version 7.0 to 7.3f.

Fixed in development version: 9 Jun 2005.

Fix included in release version: 7.4

Kiii values calculated from nodal displacements are twice as big as they should be. This in turn affects the Gequiv term calculated from Ki, Kii and Kiii.

If *ENERGY RELEASE RATE, PREDICTION=DISPLACEMENT is used in a growth analysis and there is significant Kiii, the crack growth rate will be higher than it should be since the Kiii contribution is too large.

If *ENERGY RELEASE RATE, PREDICTION=ENERGY is used in a growth analysis the displacement-based Kiii values are only for report purposes and the growth prediction is unaffected by the bug.

Workaround: None.


ZENCR311

Applies to: Version 7.0 to 7.3f.

Fixed in development version: 13 May 2005.

Fix included in release version: 7.4

Paris and Walker crack growth options do not allow a power of less than 2.0.

Workaround: For Paris use TYPE=DELTA K POINTS. For Walker use TYPE=TABULAR.


ZENCR310

Applies to: Version 7.3f (also probably 7.0 to 7.3e, but these have not been verified).

Fixed in development version: 13 May 2005.

Fix included in release version: 7.4

Some nodes may be reported as having "closed" status when they obviously should be "open". This is only likely to occur for non-planar crack faces that extend 360 degrees of a circular crack front.

Workaround: None.


ZENCR309

Applies to: Version 7.3 User Manual, Issue 7.3 Revision 0, page 99
Applies to: Version 7.2 User Manual, Issue 7.2 Revision 0, page 96
Applies to: Version 7.1 User Manual, Issue 7.1 Revision 0, page 96

Fix included in release version: Version 7.4 User Manual

Equation 5-15 should contain da/dt on the left hand side, not da/dN. The description following the equation should contain "t - time" in place of "N - numbr of fatigue cycles".


ZENCR308

Applies to: Version 7.1 to 7.3f (Abaqus interface only).

Fixed in development version: 27 Apr 2005.

Fix included in release version: 7.4

Surface update on all faces of an element on the Abaqus *SURFACE option (i.e. element specified without any face id) causes an array bounds error at line 299 (in v7.3f) of surfabq if:

  • the element is specified as an element number (with or without a trailing comma), and,
  • the element is one that is replaced by a crack-block.

Workaround: Specify the element on six data lines with one face id per data line, rather than just one data line without any face id.


ZENCR307

Applies to: Version 7.3f (also probably 7.0-7.3e, but these have not been verified) (Abaqus interface only).

Fixed in development version: 13 Jul 2005.

Fix included in release version: 7.4

The Abaqus *SYSTEM command is not always handled correctly by Zencrack if points A and B are defined but point C is not defined.

Workaround: To address any potential issue with *SYSTEM, ensure that points A, B and C are fully defined.


ZENCR306

Applies to: Version 7.3f (also probably 7.0 to 7.3e, but these have not been verified) (Abaqus interface only).

Fixed in development version: 26 Apr 2005.

Fix included in release version: 7.4

An array bounds problem can occur at line 635 (in v7.3f) of routine insabq if *CONTACT is used in the zcr file and a split set is defined that has a zero for one of the elements.

Workaround: None.


ZENCR305

Applies to: Version 7.3f (also probably 7.0 to 7.3e, but these have not been verified).

Fixed in development version: 29 Apr 2005.

Fix included in release version: 7.4

An array bounds problem can occur at line 153 (in v7.3f) of routine facetinitialsplit if there are a large number of split element pairs (several hundred). The problem is also dependent on a high number of elements along a crack front in combination with a high number of split pairs.

Workaround: None.


ZENCR304

Applies to: User Manual for versions 7.0 to 7.3.

Fix included in release version: Version 7.4 User Manual

In the description of keyword *OUTPUT, the default for option FE DISPS is stated to be YES. This is incorrect - the default is NO.


ZENCR303

Applies to: Version 7.3f (also probably 7.0 to 7.3e, but these have not been verified) (Marc interface only).

Fixed in development version: 14 Feb 2005.

Fix included in release version: 7.4

Coordinates may be incorrect in a Marc analysis after transfer of crack-blocks to a new location. This is only likely to cause problems when there is large non-planar growth.

Workaround: None.


ZENCR302

Applies to: Version 7.3 to 7.3f (Unix versions and Ansys interface only).

Fixed in development version: 15 May 2006.

Fix included in release version: 7.4a

In the Unix runzcr73 script the symbol FETYPE is incorrectly set to the value "solidmodel" if the Ansys option "-a solidmodel" is used on the command line.

Workaround: Fix this problem by locating these lines in the runzcr73 file:

case $CNVANSYS in
     N* | n*) CNVANSYS=normal   ;;
     S* | s*) FETYPE=solidmodel ;;

and correcting the third of the lines as below:

case $CNVANSYS in
     N* | n*) CNVANSYS=normal   ;;
     S* | s*) CNVANSYS=solidmodel ;;

ZENCR301

Applies to: Version 7.3f (also probably 7.0 to 7.3e, but these have not been verified) (Marc interface only).

Fixed in development version: 26 Jan 2005.

Fix included in release version: 7.4

In the Marc interface elements may be missing from the cracked mesh from fe analysis 2 onwards if crack-blocks with different numberes of elements are used in the analysis.

Workaround: None.


ZENCR300

Applies to: Version 7.3f - HP-UX version only.

Fixed in development version: 14 Jan 2005.

Fix included in release version: 7.4

An error 4089 "can't find a node" may occur when *MAPPING,MIDSIDE=CURVED is used. The same job is okay with the default option of *MAPPING,MIDSIDE=STRAIGHT.

Workaround: None, other than using the default *MAPPING,MIDSIDE=STRAIGHT.


ZENCR298

Applies to: Version 7.4, 7.5 - all interfaces.

Applies to: Version 7.1 to 7.3f - Abaqus and Ansys interfaces only.

Fixed in development version: 23 Apr 2008.

Fix included in release version: 7.5-10

An analysis with temperature interpolation can give an unexpected error 4125 stating that temperature cannot be interpolated for a particular node. This occurs because the node falls fractionally outside the boundary of the uncracked mesh as a result of the mesh modification process.

The fix to bug ZENCR366 should address this issue for the majority of cases.

Workaround for v7.3f, v7.4, v7.5: Use *CONTROLS,tolshape1=x with a value of x of 1.01. Keep increasing x in steps of 0.01 until the problem is resolved. If the problem persists and is for a midside node on the split element part of a crack face, a second option is to user *CONTROLS,itolsplit=1. This may result in some midside nodes on split elements of the crack faces being away from their midside positions, but should allow the analysis to progress.

Workaround for v7.1 to 7.3e: Use *CONTROLS,tolshape=x with a value of x of 1.01. Keep increasing x in steps of 0.01 until the problem is resolved.


ZENCR297

Applies to: Version 7.0 to 7.3e.

Fixed in development version: 2 Dec 2004.

Fix included in release version: 7.3f

Some analyses can end with error 4034 where no error would be expected. This occurs because a point cannot be located/positioned in the crack history. Additional code has been implemented in v7.3f to provide a back-up method of positioning the point if the normal approach fails. This fixes some error 4034 problems.

Workaround: None.


ZENCR296

Applies to: Version 7.3 to 7.3e (Ansys interface only).

Fixed in development version: 30 Nov 2004.

Fix included in release version: 7.3f

Temperatures are not interpolated correctly to internal crack-block nodes if boundary shifting is activated. If the temperature distribution is not too severe or the crack-block does not shift far from its original position, then the temperatures are likely to be acceptable.

Workaround: None.


ZENCR295

Applies to: Version 7.1 to 7.3e - Abaqus and Ansys interfaces only.

Fixed in development version: 30 Nov 2004.

Fix included in release version: 7.3f

Temperature interpolation may produce a temperature of zero on one of the original mesh nodes that is shared by adjacent crack-blocks. This problem only occurs if there are multiple crack-blocks and boundary shifting is activated - even then there are some job dependency issues and the problem will probably not occur. A visual check of the temperature contours in the cracked mesh is recommended (select only the crack-blocks for display).

Workaround: Change the order of the crack-blocks in the input file.


ZENCR294

Applies to: Version 7.3 to 7.3e (earlier versions not checked)

Fixed in development version: 2 Dec 2004.

Fix included in release version: 7.3f

Two issues have been identified in relation to definition of tangents, normals and VCEs for crack front nodes:

  • For some crack geometries the VCE definitions may not be as sensible as would be expected. The raw energy release rate results may appear to be discontinuous or negative. The subsequent processing to calculate Gmax will, however, be valid for the majority of affected cases. If there is a problem it will manifest itself as a reversal of the crack growth direction from that which is expected.
  • Tangents and normals at the free surfaces may not be as accurate as they should be for cases where both sides of the crack are modelled and the outer surface is curved. This has a small effect on analysis results.

Workaround: None.


ZENCR293

Applies to: Version 7.0 to 7.3e.

Fixed in development version: 25 Nov 2004.

Fix included in release version: 7.3f for PC-Windows, 7.4a for all platforms

The output table in the .rep file that reports displacements for crack face node pairs only allows report of node numbers up to 99999. Higher numbers are shown as ***** e.g.:

 CRACK  FACE NODES SIDES 1/2    DX side 1    DY side 1    DZ side 1    DX side 2    DY side 2    DZ side 2
    1    *****     6778        7.1474E-03   5.0520E-01  -1.4755E-03   7.2454E-03   5.0430E-01  -2.1202E-03
    1    91593    98685        7.1409E-03   5.0520E-01  -2.4826E-03   7.2287E-03   5.0430E-01  -3.0723E-03
    1    91597    98688        7.1356E-03   5.0510E-01  -3.4904E-03   7.2101E-03   5.0430E-01  -4.0024E-03

This is a reporting issue only and does not affect the analysis or any results processing.

Workaround: None.


ZENCR292

Applies to: Version 7.3 to 7.3e (earlier versions have not been checked).

Fixed in development version: 18 Nov 2004.

Fix included in release version: 7.3f

There may be an array bounds problem in routine facetinitialsplit while generating the initial cracked mesh if the following conditions are met:

  • the model has more that one split set defined
  • one of the split sets has more than about 125 split pairs (the exact number is dependent on the model e.g. the number and type of crack-blocks will affect the number of split pairs that can be used before experiencing a problem)

Workaround: None.


ZENCR291

Applies to: Version 7.0 to 7.3e (Abaqus interface only).

Fixed in development version: 5 Nov 2004.

Fix included in release version: 7.3f

The supplied Abaqus user subroutines, zcr-jint and zcr-ctint, which can be used to extract results from the Abaqus fil file (using *ENERGY RELEASE RATE, RESULTS=FIL-USER and *USER), do not work correctly for fil files with one million or more records.

Workaround: A workaround is to remove all requests in the uncracked mesh for output to the fil file. The file should then be less than 1 million records and will be processed correctly.


ZENCR290

Applies to: Version 7.0 to 7.3e (Abaqus interface only).

Fixed in development version: 30 Nov 2004.

Fix included in release version: 7.3f

If the Abaqus *SYSTEM keyword is used in an analysis which uses the Zencrack option *BOUNDARY SHIFT, TYPE=TRANSFER, the nodal coordinates in the cracked mesh after the *SYSTEM option may be incorrect after the crack-blocks have transferred to a new location.

Workaround: Modify the uncracked mesh so that *SYSTEM is not required.


ZENCR289

Applies to: Version 7.0 to 7.3d (Abaqus interface only).

Fixed in development version: 29 Oct 2004.

Fix included in release version: 7.3e

A Fortran out of bounds error occurs in routine modabq if an ELSET option with the GENERATE parameter in the uncracked mesh contains more than 1000 data lines.

Workaround: Repeat the *ELSET line to split up the set definition ensuring that each block of data has less than 1000 lines.


ZENCR288

Applies to: 3dmesh utility version 7.03.

Fixed in development version: 17 Sep 2004.

Fix included in release version: 7.3e (utility version 7.04)

The generated .inp file contains corrupted data instead of ** comment characters if the default of Abaqus is selected by hitting return when prompted:

Do you want an Abaqus, Ansys or Marc file ?
(enter a, n or m - default is a)

Workaround: Enter a when prompted with the above question.


ZENCR287

Applies to: Version 7.0 to 7.3d (Abaqus interface only).

Fixed in development version: 4 Oct 2004.

Fix included in release version: 7.3e

If an element set contains more than 50000 elements but the mesh has less than 50000 elements an array bounds error will occur. Windows versions will stop with a Fortran traceback. SG versions continue and eventually report an error because internal data has been corrupted (error 4054 has been observed).

Workaround: Ensure all element sets contain <=50000 elements.

Note: the limiting value is 40000 in v7.0, 50000 for 7.1 to 7.3d and 75000 from 7.3e


ZENCR286

Applies to: Version 7.1 to 7.3c (Ansys interface only).

Fixed in development version: 27 Aug 2004.

Fix included in release version: 7.3d

If element split sets are defined in the zcr file, the line of data in the uncracked mesh before the EN line for each split element is deleted in the cracked mesh file. The missing line is most likely to be an EMORE line for the preceeding element.

Workaround: Place a comment line before each split element in the uncracked mesh (and before each element that may become a split element if *BOUNDARY SHIFT, TYPE=TRANSFER is used).


ZENCR285

Applies to: Version 7.0 to 7.3c.

Fixed in development version: 7 Sep 2004.

Fix included in release version: 7.3d

The crack growth data option "delta G points" requires input of the stress ratio for which the data applies. It is not stated in the documentation that the equations used are only implemented for R=>0. If a value of R<0 is entered the calculation of da/dN will be unreliable. If R=-1 the program fails with a Fortran error in routine growthnode. The fix prevents use of R<0 with this option.

Workaround: Use an alternative crack growth data option.


ZENCR284

Applies to: Version 7.0 to 7.3c.

Fixed in development version: 7 Sep 2004.

Fix included in release version: 7.3d

If Gmax from the energy approaches in the Abaqus and Marc interfaces is negative for a crack front node, Zencrack assumes that Gmin has been found and makes the G value positive and reverses the growth direction for the node. This can give incorrect crack growth. This can only occur if the analysis has one set of VCEs (i.e. a symmetry model or if *GROWTH CONTROLS,DIRECTION=INITIAL or PREFERRED is used). Note that the Gmax term that is calculated form the f.e. analysis results should always be positive. A negative value suggests a numerical issue or path dependence in the contour results. (This is not the same as Zencrack applying a negative sign to a Gmax value to indicate that the crack is closing).

Workaround: Contact Zentech for details - requires use of zcr-jint subroutine to modify the -ve value before it reaches Zencrack.


ZENCR283

Applies to: Version 7.1 to 7.3c.

Fixed in development version: 17 Aug 2004.

Fix included in release version: 7.3d

A model with split sets may given an unexpected error 4089 "unable to find node xxx" when generating the initial mesh if the uncracked mesh has 8 noded bricks and the crack front contains quarter circular crack-blocks.

Workaround: Redo the uncracked mesh using 20 noded brick elements.


ZENCR282

Applies to: Version 7.0 to 7.3c.

Fixed in development version: 10 Aug 2004.

Fix included in release version: 7.3d

Tab characters in the uncracked mesh may cause the Zencrack mesh reader to report an "unrecognised data" error or the data line containing the tab may not be treated correctly. In the latter case a cracked mesh is created but it may be incorrect.

Workaround: Replace tabs in the uncracked mesh by spaces.


ZENCR281

Applies to: Version 7.3 to 7.3c (Ansys interface only).

Fixed in development version: 4 Aug 2004.

Fix included in release version: 7.3d

Zencrack fails reading in materials data file jobname.mp for jobs that use the "-a solidmodel" command line option. The error occurs because of problems with trailing commas generated in intermediate files by Ansys for materials with temperature dependent properties.

Workaround: None.


ZENCR280

Applies to: Version 7.0 to 7.3c (Abaqus interface only).

Fixed in development version: 6 Aug 2004.

Fix included in release version: 7.3d

Data on a *BOUNDARY line in the following format: node # , dof # , 0

is interpreted by Abaqus as being equivalent to: node # , dof # , dof # , 0

But it is interpreted incorrectly by Zencrack. If fixities on crack-block nodes that are to be updated are applied in this way, the nodes are correctly removed from the *BOUNDARY data but no updates appear in the cracked mesh.

Workaround: Use either of the standard input formats for *BOUNDARY:

node # , dof # , dof # , 0

or

node # , dof # , , 0.


ZENCR279

Applies to: Version 7.0 to 7.3c (Abaqus interface only).

Fixed in development version: 5 Aug 2004.

Fix included in release version: 7.3d

If points B and/or C are left blank on the data lines of the Abaqus *SYSTEM keyword, the coordinate system change may not be calculated correctly by Zencrack.

Workaround: Always define points B and C on the *SYSTEM data lines.


ZENCR278

Applies to: Version 7.0 to 7.3c.

Fixed in development version: 6 Aug 2004.

Fix included in release version: 7.3d

An array bounds error can occur if all the following conditions are met:

  • the analysis is a crack growth analysis.
  • each f.e. analysis has multiple sets of energy release rate / displacement results.
  • the number of results sets varies between f.e. analyses (due to non-linear effects).
  • Zencrack is attempting to process all the available results sets (e.g. *ENERGY RELEASE RATE, STEPS is used with a frequency of 1).

Workaround: In the Abaqus interface do not use the *ENERGY RELEASE RATE, STEPS option - the default will then be one set of results per Abaqus load step. The total number of results sets will not change from one f.e. analysis to the next.


ZENCR277

Applies to: Version 7.3 to 7.3c (Ansys interface only).

Fixed in development version: 4 Aug 2004.

Fix included in release version: 7.3d

Zencrack gives an array bounds error at line 1898 of routine modansys if TSHAP,QUA8 is used.

Workaround: None.


ZENCR276

Applies to: Version 7.0 to 7.3c.

Fixed in development version: 3 Aug 2004.

Fix included in release version: 7.3d

A job may unexpectedly give an error 4095 or 4034 while generating the initial cracked mesh. The error that is reported depends upon the mapping options that are selected on *MAPPING. Note that these errors may also occur for valid reasons and not because of the bug.

Workaround: None.


ZENCR275

Applies to: Version 7.3 to 7.3b - Ansys interface on Windows machines only.

Fixed in development version: 13 Jul 2004.

Fix included in release version: 7.3c

The value of ZCRANSYS is not set correctly in the runzcr73.bat file by the setup program setupzcr73 if an Ansys product is specified AND the Ansys location contains spaces. The closing double quote that should be around the Ansys executable is instead placed at the end of the ZCRANSYS string. The comments in the runzcr73.bat file regarding the closing double quote are also incorrect. The program correctly replaces the spaces with the # symbol in the batch file e.g.

set ZCRANSYS="c:\program#files\ansys#inc\v80\ansys\bin\intel\ansys.exe#-p#struct"   <- incorrect

set ZCRANSYS="c:\program#files\ansys#inc\v80\ansys\bin\intel\ansys.exe"#-p#struct   <- correct

With the incorrect definition for ZCRANSYS the analysis produces a screen error when a Zencrack job attempts to execute Ansys:

'c:\program' is not recognized as an internal or external command, operable program or batch file.

Workaround: Edit the runzcr73.bat file and correct the definition of ZCRANSYS.


ZENCR274

Applies to: Version 7.1 to 7.3b.

Fixed in development version: 29 Jun 2004.

Fix included in release version: 7.3c

If a temperature time history is to be used (by specifying *TEMPERATURE, TYPE=TIME HISTORY), but no temperature time history is defined (on *LOAD SYSTEM) or the temperature time history has less than 2 points, Zencrack will stop due to a fortran file error on unit 91 at line 50 of getinfo_temp.

Workaround: Ensure that the temperature time history file is correctly defined if required i.e. has at least 2 points.


ZENCR273

Applies to: Version 7.1 to 7.5-12 (Abaqus interface only).

Fixed in development version: 7 Jul 2008.

Fix included in release version: 7.5-13

If a trailing comma is included after the last node in the connectivity data for 8 noded bricks, or if the connectivity stretches over more than one data line, the connectivity is not read correctly by Zencrack.

Workaround: Remove trailing commas and place all 8 nodes on the first data line.


ZENCR272

Applies to: Version 7.0 to 7.3b (Abaqus interface only).

Fixed in development version: 24 June 2004.

Fix included in release version: 7.3c

If the *CONTACT keyword is used for an 8 noded mesh, Zencrack generates two keywords in the cracked mesh file that are not required. There is no data line for the unnecessary *SURFACE keyword and this causes Abaqus to stop with an error.

Workaround: A workaround is available by pasting data from the cracked mesh into the uncracked mesh file and removing the incorrect lines. Contact us for more details.


ZENCR271

Applies to: Version 7.1 to 7.3b.

Fixed in development version: 23 June 2004.

Fix included in release version: 7.3c

Some 8 noded models may give the following error: "***ERROR 4089 Unable to find node ************".

Workaround: None.


ZENCR270

Applies to: Version 7.1 to 7.3b.

Fixed in development version: 29 Jun 2004.

Fix included in release version: 7.3c

The error message for an incorrect parameter on keyword *MEMORY states that TIME HISTORY is a valid parameter rather than TIME. The TEMPERATURE parameter is not included in the error message. In addition, some warning messages state that the *MEMORY keyword has a parameter TIME HISTORY. These reports should state that the parameter is TIME.


ZENCR269

Applies to: Version 7.0 to 7.3b.

Fixed in development version: 30 Jun 2004.

Fix included in release version: 7.3c

The user manual states that comment lines starting with a # character are allowed in spectrum, time history and temperature history files and sub-files. But including a comment in one of these files generates an error.

Workaround: Remove comments from affected file(s).


ZENCR268

Applies to: Version 7.1 to 7.3b (Ansys interface only).

Fixed in development version: 25 Jun 2004.

Fix included in release version: 7.3c

A number of issues have been identified in the Ansys interface:

  • problems with NSEL command:
    • NSEL,NONE is required at the start of generation of NSEL commands for node set components
    • generated NSEL commands may have format errors
    • some node sets may be created more than once in the cracked mesh
    • node set NALL is not written correctly (must be requested using *NODE SETS,ALL)
  • problems with ESEL command:
    • may cause an out-of-bounds error
    • errors for parameters TYPE
    • commands that do not require processing cause an error
  • problems with the handling of the R keyword
  • duplicate surface elements can be written for contact or target surface elements when using the "-a solidmodel" command line option
  • element types other than 8 or 20 noded bricks may not be handled correctly
  • displacement results are not extracted correctly if there are 3 or more crack fronts in the model or if there are 2 crack fronts in which both sides of the crack are modelled.


ZENCR267

Applies to: Version 7.0 to 7.3b (Marc interface only).

Fixed in development version: 30 Jun 2004.

Fix included in release version: 7.3c

In an analysis with crack-block transfer where only one side of the crack is modelled, the symmetry boundary conditions are not removed after transfer. The "open" crack face will not open properly due to the unwanted constraints. This problem is easily identified in deformed plots of the cracked mesh after transfer.

Workaround: Use a full model rather than a symmetry model.


ZENCR266

Applies to: Version 7.3 User Manual, Issue 7.3 Revision 0, page 265
Applies to: Version 7.2 User Manual, Issue 7.2 Revision 0, page 251
Applies to: Version 7.1 User Manual, Issue 7.1 Revision 0, page 251

Fix included in release version: Version 7.4 User Manual

In the description of the THRESHOLD keyword, the following statement:

Kth      The time based threshold is defined using a single value of deltaKth.

should be:

Kth      The time based threshold is defined using a single value of Kth.

The description that follows later in the section "Data Lines" is correct.


ZENCR265

Applies to: Version 7.0 to 7.3a (Marc interface only).

Fixed in development version: 15 Jun 2004.

Fix included in release version: 7.3b

The connectivity in an 8 noded model is always generated as element type 7 even if the uncracked mesh contained a different element type (e.g. 117).

Workaround: None.


ZENCR264

Applies to: Version 7.0 to 7.3a (Marc interface only).

Fixed in development version: 15 Jun 2004.

Fix included in release version: 7.3b

No checks are made on the element type for replaced elements. If an invalid type is specified, there is likely to be an error or the analysis may be incorrect. For example, Zencrack gives an array bounds error at line 260 of routine relaxsurfset1 if all replaced elements are invalid types for replacement. Valid element types for crack-block elements are:

  • for 20 noded elements: types 21, 35, 57, 61, 44, 71
  • for 8 noded elements: types 7, 117, 43, 123.

Workaround: Only replace the listed element types with crack-blocks.


ZENCR263

Applies to: Version 7.0 to 7.3a (Marc interface only).

Fixed in development version: 15 Jun 2004.

Fix included in release version: 7.3b

Zencrack gives an array bounds error at line 90 of routine parmarc if the Marc ALIAS parameter is used for an element type of greater than 99.

Workaround: Manually modify the element type in the connectivity to remove the need for an alias.


ZENCR262

Applies to: Version 7.1 to 7.3a.

Fixed in development version: 10 Jun 2004.

Fix included in release version: 7.3b

In an analysis with time dependence and superposition method 1 there is a chance of a divide by zero error when calculating the growth direction if the instantaneous total Gmax is exactly zero. If the problem occurs, the program stops with a Fortran error.

Workaround: None.


ZENCR261

Applies to: Version 7.1 to 7.3a.

Fixed in development version: 9 Jun 2004.

Fix included in release version: 7.3b

Zencrack gives a -ve square root error at line 405 of routine integrate_dadt (line 408 in v7.3a) if an analysis that includes time dependent crack growth has a load system of type=superposition in the spectrum.

Workaround: None.


ZENCR260

Applies to: Version 7.1 to 7.3a.

Fixed in development version: 10 Jun 2004.

Fix included in release version: 7.3b

In a combined time and fatigue growth analysis it is possible for a cycle to be integrated at the end of one integration step and again at the start of the next. This is most likely to occur if the growth due to da/dt effects is much lower than that due to da/dn effects.

Workaround: None.


ZENCR259

Applies to: Version 7.1 to 7.3a.

Fixed in development version: 8 Jun 2004.

Fix included in release version: 7.3b

Zencrack gives an array bounds error at line 250 of routine reportkey15 if an analysis that includes time dependent crack growth meets any of the following criteria:

  • if a load system is defined without a time history file when one is required; in this case a correct error 2200 is reported before the program fails
  • if the time history associated with a spectrum has 2 or less points.

Workaround for item 1: Add a time history file as per the error message 2200.

Workaround for item 2: If there are 0 or 1 data points, the input data is invalid. There must be at least 2 points in a time history. So the data should be corrected. If two points define a full history, a third point should be added (e.g. midway between the existing points).


ZENCR258

Applies to: Version 7.1 to 7.3.

Fixed in development version: 2 Jun 2004.

Fix included in release version: 7.3a

Zencrack may give a Fortran -ve square root error at line 86 of routine kicexceeded if an analysis that includes time dependent crack growth has a non-zero Poisson ratio. The error occurs during integration after the first f.e. analysis. Analyses with zero Poisson ratio are correct. Fatigue-only crack growth is not affected.

Workaround: Set the Poisson ratio to zero on the *MATERIAL keyword. This will give a slightly different solution to a true fix, but the results should be indicative of the correct behaviour.


ZENCR257

Applies to: Version 7.0, 7.1, 7.2 (Abaqus interface only) (with Abaqus 6.4-1 or later).

Fixed in development version: 5 Apr 2004.

Fix included in release version: 7.3

Zencrack may not read crack front nodal temperature values correctly from an analysis carried out with Abaqus 6.4. The same analysis is processed correctly if run with Abaqus 6.3. This is due to a format change in the Abaqus .dat file.

If an Abaqus analysis contains temperatures the crack front nodal temperatures are always reported in the rep file in the table headed "TEMPERATURE VALUES FROM ABAQUS OUTPUT FILE, SET xxx". This table will be incorrect for jobs run with Abaqus 6.4-1 or later.

The incorrect temperature values only affect the processing of the f.e. results if the zcr file contains the option *TEMPERATURE, TYPE=FE and temperature dependent material data has been specified.

Workaround: Use Abaqus 6.3.


ZENCR256

Applies to: Version 7.1, 7.2 (Ansys interface only).

Fixed in development version: 8 Mar 2004.

Fix included in release version: 7.3

If an Ansys jobs fails at f.e. analysis 2 or later during a crack growth run (e.g. due to a "distorted element" error message), Zencrack continues to use the displacements obtained for the last successful f.e. analysis and fails to recognise that Ansys reported an error. The analysis results are incorrect after the first f.e. step that fails to run.

Workaround: This problem is most likely to arise because of element distortion errors issued by Ansys. These can be turned off by adding the following command before the connectivity data of the uncracked mesh file:
SHPP,OFF


ZENCR254

Applies to: Version 7.1, 7.2 (Ansys interface only).

Fixed in development version: 18 Feb 2004.

Fix included in release version: 7.3

Constraint equations generated for crack-blocks that require them are incorrect in the Ansys interface. Results from the analysis will be incorrect. Affected crack-blocks are:

  • sq112x4.sup
  • sq160x4.sup
  • sq38x2.sup

(Reminder: crack-block sq38x2.sup should not be used with the Ansys interface due to a collapsed element configuration inside the crack-block that is not supported by Ansys.)

Workaround: None.


ZENCR253

Applies to: Version 7.1, 7.2 (Ansys interface only).

Fixed in development version: 2 Apr 2004.

Fix included in release version: 7.3

A comment character, !, placed on a data line of the uncracked mesh that Zencrack processes may cause the job to stop with ***ERROR 3006.

Workaround: Remove the comment or place it on the preceding line of the file.


ZENCR252

Applies to: Version 7.2 User Manual, Issue 7.2 Revision 0.
Applies to: Version 7.1 User Manual, Issue 7.1 Revision 0.

Fix included in release version: Version 7.3 User Manual, Issue 7.3 Revision 0.

A high value of ratio for fixed or variable ring size control does not have the expected effect. The ratio obtained is instead 0.4.

This happens because a check is made to prevent the ring size control producing potentially distorted element rings. This uses the control tolerance tolringlimit with a default value of 0.4 and has the effect of limiting the ring ratio values input by the user to this upper bound. To allow any fixed or variable ring size, this tolerance should be set to 1.0 using:

*CONTROLS,TOLRINGLIMIT=1.0

Although this tolerance is listed under the *CONTROLS keyword, it is not described elsewhere in the documentation where it would be more useful.


ZENCR251

Applies to: Version 7.2 User Manual, Issue 7.2 Revision 0.
Applies to: Version 7.1 User Manual, Issue 7.1 Revision 0.

Figure 11-1 of the user manual does not indicate that crack-block sq112ax4 is a large crack-block. It is correctly listed in Figure 11-2.


ZENCR250

Applies to: Version 7.0, 7.1, 7.2.

Fixed in development version: 14 Feb 2004.

Fix included in release version: 7.3

Surface normal pressures (other than on crack faces) are missing on both the original target crack blocks and the updated crack block elements after transfer of crack blocks to new locations using *BOUNDARY SHIFT, TYPE=TRANSFER. When the crack-block is in the original location, all pressure load updates are correct.

Workaround: None.


ZENCR249

Applies to: Version 7.0, 7.1, 7.2.

Fixed in development version: 31 Jan 2004 - for Abaqus interface only, 14 Feb 2004 - for Ansys and Marc interfaces.

Fix included in release version: 7.3

Loads on faces of crack-blocks other than the crack face can cause errors in the load update for split set elements.

Workaround: Try placing the crack face load first in the list of loads in the uncracked mesh.


ZENCR248

Applies to: Version 7.0, 7.1, 7.2.

Fixed in development version: 31 Jan 2004.

Fix included in release version: 7.3

A blank line as input for data line 1 on keyword *CRACK FRONT causes an end of file error at line 218 of routine getkey07.

Blank data lines for other keywords that have required data items are correctly trapped and an error message given. The error message could be more helpful as it indicates "an error in the following data" then echoes a blank line.

Workaround: Correct or remove the blank data line in the zcr input file.


ZENCR247

Applies to: Version 7.1, 7.2 (Abaqus interface only).

Fixed in development version: 31 Jan 2004.

Fix included in release version: 7.3

An analysis with load on multiple faces of the crack-block may cause an out of bounds error at line 315 of routine loadit if transition elements are used.

This is due to incorrect allocation of arrays related to load updates when transition elements are used. This problem can only occur if transition elements are used and is dependent on the selected crack-block that is used and the number of transition elements. The higher the number of transition elements the more likely that the error will occur.

Workaround: None.


ZENCR246

Applies to: Version 7.1, 7.2.

Fixed in development version: 31 Jan 2004.

Fix included in release version: 7.3

Extrapolation of values to nodal positions on the crack front may be incorrect for node position 1 when there is more than 1 element along the crack front. This is most obvious in the extrapolated SIF values calculated using the displacement method. The error is very small - typically fractions of 1%.

In v7.1 and v7.2 the incorrect extrapolation of displacement based SIF values does not affect analysis results because of bug zencr241.

Workaround: None.


ZENCR245

Applies to: Version 7.1, 7.2 (Abaqus interface only).

Fixed in development version: 27 Jan 2004.

Fix included in release version: 7.3

A mesh generation error occurs as a result of an input data error. This leads to an array bounds error at line 361 of routine dldabq. Correcting the input data to remove the mesh generation error solves the problem.

When Zencrack encounters a problem generating the cracked mesh an attempt can be made to write what data has been generated for the cracked mesh even though there is an error. In some cases this can help identify the problem. If two crack-blocks that cannot be merged are placed next to one another an error is generated and an attempt is made to write the cracked mesh data. If there is a *DLOAD option in the uncracked mesh the program fails while writing the mesh with an array bounds error at line 361 of routine dldabq.

Workaround: Correcting the input data to remove the mesh generating error solves the problem. However, if you want to allow the program to write the cracked mesh that it was attempting to generate at the time of the array bounds error, you must remove all *DLOAD options from the uncracked mesh file and retain all remaining (incorrect) input data.


ZENCR244

Applies to: Version 7.1, 7.2.

Fixed in development version: 23 Jan 2004.

Fix included in release version: 7.3

The value of the third argument, NFE, that is passed into user subroutine user_transfercf is the number of the next f.e. analysis not the number of the previous f.e. analysis.

Workaround: Take this into account when coding the subroutine.


ZENCR243

Applies to: Version 7.1, 7.2.

Fixed in development version: 27 Jan 2004.

Fix included in release version: 7.3

When a crack front attempts to transfer into the final element(s) before a free surface the program will fail with error 6012 and/or 6013.

Workaround: None.


ZENCR242

Applies to: Version 7.1, 7.2.

Fixed in development version: 23 Jan 2004.

Fix included in release version: 7.3

When there are only 2 corner node positions on a crack front, extrapolation of values to the crack front nodal positions is incorrect. The extrapolated values are an average of the base values used to drive the extrapolation. This may affect the following:

  • extrapolation of displacement based stress intensity factors to the crack front nodal positions (in this case, due to bug zencr241 these slightly incorrect values are not used in growth prediction)
  • calculations related to G and dG/da during update of crack front positions after crack growth.

This problem arises if a crack front contains a single crack-block of type st16x1, st19x1, st23x1, st26x1, st28x1, st28cx1, st35x1.

Workaround: None.


ZENCR241

Applies to: Version 7.1, 7.2.

Fixed in development version: 23 Jan 2004.

Fix included in release version: 7.3

The plane strain stress intensity values derived from displacements are extrapolated to crack front nodal positions and reported at those points. If a crack growth analysis is carried out using displacement based values, the original stress intensity factors are used rather than the values extrapolated to the node positions. The effect of this error is greatest in meshes where the element edges at the crack front are not normal to the crack front.

Workaround: None.


ZENCR240

Applies to: Version 7.1, 7.2.

Fixed in development version: 23 Jan 2004.

Fix included in release version: 7.3

When a displacement based solution is used to drive a crack growth analysis, the values reported in the table of conversion of energy results to stress intensity factors are incorrectly based on displacement derived Gequiv values rather than the Gmax values from the energy solution. This is a reporting issue only and does not affect the analysis results.

Workaround: None.


ZENCR239

Applies to: Version 7.1, 7.2.

Fixed in development version: 23 Jan 2004.

Fix included in release version: 7.3

Part way into the analysis a mixed mode crack growth analysis with 2 crack fronts gives correct growth on one crack front and incorrect growth on the other crack front. At the incorrect crack front the shared crack face nodes on the crack-block / split set interface are incorrectly mapped onto an extension of the original crack faces rather than the calculated growth history.

This problem can only arise if all the following conditions are met:

  • at least one split element set is included in the model
  • more than one crack front is connected to a single split set
  • crack growth is non-planar for these crack fronts
  • boundary shifting causes the crack face nodes of the split set elements to fall beyond the edge of the initial crack face definition.

Workaround: None.


ZENCR237

Applies to: Version 7.1, 7.2.

Fixed in development version: 23 Jan 2004.

Fix included in release version: 7.3

The value of Gequiv calculated from displacement based stress intensity factors is always reported as positive, even in a mode I problem where the crack is closed. The Ki stress intensity factor has correct -ve sign in such cases. The consequence is that if displacement based values are used to drive the crack growth calculation when Ki is -ve, the values of Gequiv are incorrect and the growth prediction will be incorrect.

Workaround: None.


ZENCR236

Applies to: Version 7.1, 7.2 (Abaqus interface only).

Fixed in development version: 23 Jan 2004.

Fix included in release version: 7.3

The TRANSITION parameter on keyword CRACK FRONT causes the analysis to fail if a value of 1 is used. There are two possibilities:

  • if there are transition elements attached to only one face of the crack-block then the program gives an array bounds error at line 531 of normal.f
  • if there are transition elements attached to more than one face of the crack-block the program reports "***ERROR 4005 - CRACK PLANE IS NOT VALID FOR CRACK-BLOCK n".

Note that in situation 2 it is not physically possible to use a transition element setting of 1 and that situation 1 is not a good idea if sensible results are required from the analysis.

Workaround: Change to a sensible setting for the number of transition elements or turn the feature off (by omitting the option or using a value of 0).


ZENCR235

Applies to: Version 7.0, 7.1, 7.2 (Abaqus interface only).

Fixed in development version: 23 Jan 2004.

Fix included in release version: 7.3

The STEPS option on *ENERGY RELEASE RATE for the Abaqus interface does not write out any contour integral data for a step if the frequency value for the step is set to zero. If the first step that the user defines on the STEPS data lines has frequency of zero, then the behaviour up to and including that step is consistent with what the user wants. If the step with frequency of zero is the second or later step that is defined on the STEPS data lines, the behaviour for the step is not what it should be - instead of de-activating contour integral requests with FREQUENCY=0, the value of the FREQUENCY parameter is retained from the previous analysis step.

Workaround: Add the following into the analysis step of the uncracked mesh file that is required to have FREQUENCY=0 for contour integral output:

*CONTOUR INTEGRAL, FREQ=0, CONTOURS=3
data lines e.g. Z$001,1,1,1

The data lines can be obtained by cut/paste from any *CONTOUR INTEGRAL block in a step that has data generated by Zencrack. Alternatively they can be entered manually with one line for each crack front node, starting with "Z$001,1,1,1" and ending with "Z$nnn,1,1,1" where nnn is the number of nodes on the crack front e.g. Z$005 if there are 5 nodes on the crack front.


ZENCR234

Applies to: Version 7.2 User Manual, Issue 7.2 Revision 0.
Applies to: Version 7.1 User Manual, Issue 7.1 Revision 0.
Applies to: Version 7.0 User Manual, Issue 7 Revision 1.
Applies to: Version 7.0 User Manual, Issue 7 Revision 0.

Fix included in release version: Version 7.3 User Manual, Issue 7.3 Revision 0.

An incorrect conversion factor is given in the user manual "Unit Conversions" section:

1 ksi in0.5=0.347487 MPa mm0.5

should be:

1 ksi in0.5=34.748481 MPa mm0.5.

The html unit conversion utility, FMunitconversion.htm, is correct.


ZENCR233

Applies to: Version 7.2 Installation Manual, Issue 7.2 Revision 0.
Applies to: Version 7.1 Installation Manual, Issue 7.1 Revision 0.
Applies to: Version 7.0 Windows Installation Manual, Issue 7 Revision 1.
Applies to: Version 7.0 Unix Installation Manual, Issue 7 Revision 0.

Fix included in release version: Version 7.3 Installation Manual, Issue 7.3 Revision 0.

None of the installation manuals is clear about how to set up Zencrack for use with a Zencrack user subroutine.

Additional notes for Windows:

When the setup program is executed after installation it checks for Compaq Visual Fortran being installed in the default location. If it is, the setup configures all files automatically. When the user executes a job with the "-u" command line option, the compile and link process should run smoothly.

If Compaq Visual Fortran is not installed or is installed in a non-default location, the setup program prompts for some input and then continues with the configuration.

Additional notes for Unix:

The runzcr7x script contains a variable called ZCRFORTRAN which is set to "f90". If you use some other command line option to execute your Fortran 90 compiler, you should change this variable.


ZENCR232

Applies to: Version 7.0 onwards.

Fix included in release version: 7.5

In some situations a split pair may be needed in which the crack face extends more on one face than on the other. In such cases where the "short" crack face has no elements other than the crack-block, the cracked mesh is not created correctly and a handful of nodes on opposite crack faces remain tied together.

Workaround: Include a row of dummy elements behind the crack-blocks on the "short" crack face to mate up with the "long" crack face. Then the split pair can be defined. Set the Young's modulus to a very low value for the dummy elements so that it will not affect the results.


ZENCR231

Applies to: Version 7.2 Installation Manual, Issue 7.2 Revision 0.
Applies to: Version 7.1 Installation Manual, Issue 7.1 Revision 0.
Applies to: Version 7.0 Installation Manual, Issue 7 Revision 1.
Applies to: Version 7.0 Installation Manual, Issue 7 Revision 0.

Fix included in release version: Version 7.3 Installation Manual, Issue 7.3 Revision 0.

Step 8 of the section "To install the program files" for Windows systems may cause confusion over which file is being referred to depending upon the user's view settings for the folder. The step should be re-worded for v7.2 as follows (with 72 replaced by 71 or 70 for version 7.1 and 7.0 respectively):

8. To make a desktop shortcut for Zencrack:

  • right click on the Zencrack shortcut file in the c:\zencrack72\tools directory; this is the file called "Zencrack 72" which has size 1.52kb and not the icon file "Zencrack72.ico"
  • drag it onto your desktop
  • select "Copy here" or "Create shortcut here"
  • the shortcut including the Zencrack icon should look like this after completion:
    Zencrack 7.2 icon for Windows
  • if the shortcut does not display with this icon, a re-boot may be necessary.


ZENCR230

Applies to: Version 7.1, 7.2.

Fixed in development version: 23 Jan 2004.

Fix included in release version: 7.3

The program may get trapped in an infinite loop while carrying out numerical integration of crack growth. This is only likely to occur if no proper threshold has been defined and da/dn falls below 10-15. Results are correct up to the point where the program gets stuck.

Workaround: Try defining a meaningful threshold.


ZENCR229

Applies to: Version 7.2 User Manual, Issue 7.2 Revision 0.
Applies to: Version 7.1 User Manual, Issue 7.1 Revision 0.
Applies to: Version 7.0 User Manual, Issue 7 Revision 1.
Applies to: Version 7.0 User Manual, Issue 7 Revision 0.

Fix included in release version: Version 7.3 User Manual, Issue 7.3 Revision 0.

If the same displacement boundary conditions are listed in multiple Abaqus analysis steps only the boundary conditions in the first step are updated. This most likely results in Abaqus failing to run due to having boundary conditions specified on nodes which no longer exist.

If different displacement boundary conditions are listed in multiple Abaqus analysis steps the updates applied by Zencrack may not be correct.

These issues are known limitations but are not explained in the documentation.


ZENCR228

Applies to: Version 7.1, 7.2.

Fixed in development version: 23 Jan 2004.

Fix included in release version: 7.3

Runtime math error may occur at line 150 of imap2d.f if a crack front attempts to transfer into an invalid location when *BOUNDARY SHIFT,TYPE=TRANSFER is used.

Workaround: None.


ZENCR227

Applies to: Version 7.1, 7.2 on Windows platforms.

Fixed in development version: 23 Jan 2004.

Fix included in release version: 7.3

If a crack-block name is given with anything other than lower case extension (i.e. .sup) in the .zcr file, then an error will be reported e.g.

***ERROR 1001 SYSTEM ERROR 29 OCCURRED OPENING FILE c:\zencrack72\crack.sup

The file name given in the error message is also incorrect.

Workaround: Use lowercase .sup extension to define the crack-blocks in the .zcr file.


ZENCR226

Applies to: Version 7.1, 7.2.

Fixed in development version: 23 Jan 2004.

Fix included in release version: 7.3

Array bounds error may occur in line 531 of normal.f. The error is caused when *BOUNDARY SHIFT is activated but none of the boundary nodes in the crack plane can be shifted.

Workaround: None.


ZENCR157

Fixed in: version 7.4 (fully fixed)

Fixed in: version 6.0-e (partial fix - see below)

Zencrack does not correctly update boundary conditions on crack-blocks if the boundary conditions are specified using node numbers and the option OP=NEW is used on *BOUNDARY.

Workaround 1: request node sets in the cracked mesh and apply the boundary condition to the appropriate node set(s) (keyword *NODE SETS in v7.0 onwards or set INDSET=1 in earlier versions).

Workaround 2: check that OP=NEW is essential for the correct application of the boundary conditions - if not remove it.

This is partially fixed in version 6.0-e:

  • Zencrack now adds all updated boundary conditions into the first *BOUNDARY option that occurs in the mesh. Previously a new *BOUNDARY option was generated for the updated fixities.

Previous item for this topic Unresolved bugs Bug list
Full
[Hints, tips &FAQ] Next item for this topic