Learning Forum

[Zander Fut]

Hi, 

I'm working on a crack growth analysis and facing an error which prevents the simulation from running. Initially I was using my university's Ansys but had to move to a free student version on my personal computer due to write access related errors which would be difficult to solve on the university's systems. I was able to run the static crack growth simulation on the university software, but now when I try to solve it on my free student version, I'm facing an error stating:

NUMBER OF PARAMETERS 4 FOR CGCR TABLE FOR MATERIAL 1 CANNOT EXCEED 2

I believe the CGCR refers to crack-growth fracture criterion but other than that I'm unclear what this error means and I was unable to find any information about this online. Anyone have any ideas how to work around this?

Thank you.

 

[David Weed]

Hi,

Can you show me the commands you're using to initialize the material model? There's a chance that one of the fields is off.

[ferdinand.doemling]

 

 

Hi,
I think this is a localisation problem. Workbench / Mechanical does not convert decimal and thousands separators correctly. 
Here is a screenshot from one of my DS.DAT files.

 

My system language is German. This problem first occurred in 2024R1. The corresponding workbench file was created in 2023R2.

Edit:
From the engineering data component in a fresh 2024R1 wbpj.

 

[Zander Fut]

I think this was the issue here. I remade the model in the free student version, which is a 2024R1, compared to a 2021 version used in the university and the error is now gone. 

[Zander Fut]

Apparently the issue is still occurring. I was doing static analysis earlier without the Paris' Law constants so that the was the reason the error didn't pop up.

 

But the issue seems to be just like Ferninand mentioned, any way to overcome this?

[ferdinand.doemling]

 

rather ugly hotfix: change the decimal seperator to point in your language & region settings on your machine. That’s what I have done. Fixed the issue for me.
From another post (how-to-set-a-comma-as-the-decimal-separator-in-scdm): "The symbol used for a decimal separator (point or comma) is controlled by the Windows system settings". I don't know if this also applies to all other Workbench related applications, but I have not seen any other setting that suggests otherwise.

Additional Info: I use a windows machine for some simulations, mainly because of SpaceClaim. 

 

[Zander Fut]

This actually worked, thank you!