FSI Analysis (Opristruct - Acusolve) - Error

THEODOROS BALSIS_22459

Hello everyone, 

I am currently working on an FSI (Fluid-Structure Interaction) analysis using Optistruct and Acusolve with a student license, both running version 2022.3. The analysis is a basic "flow over a plate" model that I am using for training purposes. As such, I have created simplified models for both the structural and CFD components with a minimal number of elements. 

ITo set up the CFD model, I closely followed the steps outlined in the ACU-T: 5403 Piezoelectric Flow Energy Harvester: A Fluid-Structure Interaction tutorial. Additionally, I imported the corresponding .fem model from the same tutorial to build a similar HyperMesh model for my analysis. However, upon running the simulation, I encountered the following error:

*** ERROR # 5905 ***
 Severe element distortion detected,
 analysis aborted.
 

 *** INTERNAL PROGRAMMING ERROR ***
   in file "nltranend.F", at location # 466.
  
 ****  ABORTING RUN DUE TO AN INTERNAL ERROR  ****

I would greatly appreciate any insights or advice from the community, especially from anyone who has faced a similar issue and found a solution.

Thank you in advance for your assistance.

acupro

Please attach the AcuSolve .inp and .Log files from the run.

Make sure the fluid and structure models are in the same location/orientation, and are of the same size/units also.

THEODOROS BALSIS_22459

In this response I am attaching the .fem, .inp and .Log files as well as the .STEP geometry I used for both of the models. I am positive that the location/orientation and size/units are the same for both of them. 

THEODOROS BALSIS_22459

THEODOROS BALSIS_22459 said:

In this response I am attaching the .fem, .inp and .Log files as well as the .STEP geometry I used for both of the models. I am positive that the location/orientation and size/units are the same for both of them. 

Here are the attachments

acupro

THEODOROS BALSIS_22459 said:

Here are the attachments

The AcuSolve Log file indicates this is the bounding dimensions of the fluid domain:
Dimensions =  1.0000e+03  1.0000e+03  1.5000e+03

With the material properties for air in the input file:
density 1.225, viscosity 1.781e-5, etc

The material properties are values representing MKS units.  Thus length dimension would be in meters.  Thus the overall bounding box for the air domain is 1000 m X 1000 m * 1000 m

With the wetted surface (the FSI-connecting surface) being

100 m X 3.6 m X 1000 m

Is this consistent with what you expect?

I see you have defined a multiplier-function "ForceRamp" increasing from 0 to 1 in the first 20 time steps.  You could try making that ramp over maybe 50 time steps - and applying it to the EXTERNAL_CODE command:

EXTERNAL_CODE {
    communication                       = "socket"
    socket_initiate                     = off
    socket_host                         = "localhost"
    socket_port                         = 48002
    filter                              = "none"
    multiplier_function  =  "ForceRamp"
}

In the HyperMesh CFD GUI:
Motion ribbon
Setup/Settings Tool - External Code option - Select/Indicate that Multiplier with 'Scale Fields' active and apply that Multiplier

THEODOROS BALSIS_22459

acupro_21778 said:

The AcuSolve Log file indicates this is the bounding dimensions of the fluid domain:
Dimensions =  1.0000e+03  1.0000e+03  1.5000e+03

With the material properties for air in the input file:
density 1.225, viscosity 1.781e-5, etc

The material properties are values representing MKS units.  Thus length dimension would be in meters.  Thus the overall bounding box for the air domain is 1000 m X 1000 m * 1000 m

With the wetted surface (the FSI-connecting surface) being

100 m X 3.6 m X 1000 m

Is this consistent with what you expect?

I see you have defined a multiplier-function "ForceRamp" increasing from 0 to 1 in the first 20 time steps.  You could try making that ramp over maybe 50 time steps - and applying it to the EXTERNAL_CODE command:

EXTERNAL_CODE {
    communication                       = "socket"
    socket_initiate                     = off
    socket_host                         = "localhost"
    socket_port                         = 48002
    filter                              = "none"
    multiplier_function  =  "ForceRamp"
}

In the HyperMesh CFD GUI:
Motion ribbon
Setup/Settings Tool - External Code option - Select/Indicate that Multiplier with 'Scale Fields' active and apply that Multiplier

The intended units are in the MMKS system, and you were absolutely right about the material properties. I created a custom material with the corresponding values in MMKS, and after making that change, I no longer encounter the same error. However, I initially faced an issue where the simulation couldn't run, and the solver crashed after a few iterations with the following error:

*** ERROR # 5202 ***

Maximum number of FSI iterations reached before convergence.

*** PROGRAM STOPPED: FATAL ERROR(s) ENCOUNTERED.

 

While troubleshooting this issue, I found that in the CFD model, increasing the "Maximum stagger iterations" from 20 to 100 in the physics settings under the flow tab, allowed the solution to converge, and it completed successfully—at least in OptiStruct. However, in HW-CFD, the solution still doesn’t terminate correctly, and the log file shows the following error:

acuSolve: *** ASSERTION in Function <iopWriteSock> File <iopSocket.c> Line <612>

acuSolve: *** TCP socket write error; Permission denied

acuRun: *** ERROR: error occurred executing acuSolve"

 

I tried adjusting more solver settings, but nothing seems to resolve the issue.

Additionally, I removed the "ForceRamp" multiplier since my priority now is simply to get the model to work. The only reason I had initially implemented it, was that it was included in the tutorial for the Piezoelectric Flow Energy Harvester.

acupro

THEODOROS BALSIS_22459 said:

The intended units are in the MMKS system, and you were absolutely right about the material properties. I created a custom material with the corresponding values in MMKS, and after making that change, I no longer encounter the same error. However, I initially faced an issue where the simulation couldn't run, and the solver crashed after a few iterations with the following error:

*** ERROR # 5202 ***

Maximum number of FSI iterations reached before convergence.

*** PROGRAM STOPPED: FATAL ERROR(s) ENCOUNTERED.

 

While troubleshooting this issue, I found that in the CFD model, increasing the "Maximum stagger iterations" from 20 to 100 in the physics settings under the flow tab, allowed the solution to converge, and it completed successfully—at least in OptiStruct. However, in HW-CFD, the solution still doesn’t terminate correctly, and the log file shows the following error:

acuSolve: *** ASSERTION in Function <iopWriteSock> File <iopSocket.c> Line <612>

acuSolve: *** TCP socket write error; Permission denied

acuRun: *** ERROR: error occurred executing acuSolve"

 

I tried adjusting more solver settings, but nothing seems to resolve the issue.

Additionally, I removed the "ForceRamp" multiplier since my priority now is simply to get the model to work. The only reason I had initially implemented it, was that it was included in the tutorial for the Piezoelectric Flow Energy Harvester.

Maybe try a newer version (latest is 2024) for both solvers.  If you need to increase max stagger iterations that much, the time increment (time step size) is too large - better to decrease that.

THEODOROS BALSIS_22459

acupro_21778 said:

Maybe try a newer version (latest is 2024) for both solvers.  If you need to increase max stagger iterations that much, the time increment (time step size) is too large - better to decrease that.

I will follow your recommendation to decrease the time step size to reduce the maximum stagger iterations. As an update, I identified the issue—the OptiStruct and CFD models had different final times. Once I synchronized the final times, the analysis ran smoothly, and both solvers completed successfully.

Initially, I used a small inlet velocity of 10 mm/s to ensure the analysis would run. Now, with a representative velocity of 100 km/h (or 27,777.78 mm/s), the analysis crashes on the 4th iteration. The error from OptiStruct reads:

 ****  ABORTING RUN DUE TO UNEXPECTED ERROR CONDITION  ****

 

I suspect this is due to large displacements caused by the excitation. Currently, I am troubleshooting using Altair's guide on Troubleshooting for OptiStruct Nonlinear Convergence Issues specifically focusing on convergence issue #5. However, I'm unsure if this is the best course of action.

acupro

THEODOROS BALSIS_22459 said:

I will follow your recommendation to decrease the time step size to reduce the maximum stagger iterations. As an update, I identified the issue—the OptiStruct and CFD models had different final times. Once I synchronized the final times, the analysis ran smoothly, and both solvers completed successfully.

Initially, I used a small inlet velocity of 10 mm/s to ensure the analysis would run. Now, with a representative velocity of 100 km/h (or 27,777.78 mm/s), the analysis crashes on the 4th iteration. The error from OptiStruct reads:

 ****  ABORTING RUN DUE TO UNEXPECTED ERROR CONDITION  ****

 

I suspect this is due to large displacements caused by the excitation. Currently, I am troubleshooting using Altair's guide on Troubleshooting for OptiStruct Nonlinear Convergence Issues specifically focusing on convergence issue #5. However, I'm unsure if this is the best course of action.

Now that the lower velocity works, it would make sense to re-apply the multiplier function to the EXTERNAL_CODE command.  You want the flow to stabilize before applying the full fluid forces to the structural model.  (As the velocity increases, you're hitting the structure with a larger hammer...)