DC-FSI socket error
Hello everyone,
I am trying to set up a DC-FCI scenario of external flow on a cone geometry using optistruct and acusolve. I have run the relevant tutorial from altair documentation regarding a piezoelectric energy harvester and I moved on to set up my own model, unfortunately without success. Upon input of the first time step, the analysis is terminated with the following error:
acuSolve: Time-Step= 1 ; timeInc= 5.000000e-03 ; time= 0.000000e+00
acuSolve: *** ASSERTION in Function <iopWriteSock> File <iopSocket.c> Line <612>
acuSolve: *** TCP socket write error; Permission denied
acuRun: *** ERROR: error occurred executing acuSolve"
I am convinced that this error does not have to do with the time step set up, I have chosen the same time step in the NLPARM and fluid setup as indicated in the documentation, and I have defined the same end time in both solvers. In the tutorial I encountered no such issue which makes me think that the error arises because of the boundary conditions and motion setups in the two models, but the error type does not guide me towards the specific problem. I have tried changing the BCs in various ways I consider indicative of the scenario, but the error remains the same.
More specifically, in the optistruct model, I use an SPC to fix the root of the cylinder and define in the surf set the entire exterior of the cone for the interaction area between the solvers. In acusolve I define inlet and outlets in the respective areas of the control volume and slip BCs for the rest of the sides of the control volume. Regarding the cone, I identify as external surface the entire area of the cone, and no-constrains on the surfaces of the cone except the root that is fixed in the optistruct setup.
Does anyone have any suggestions on what could be causing this problem and the rationale behind suggested solutions (if any)?
I am also attaching the hm files for both optistruct and acusolve, the .fem and .log files cci.txt and .out for convenience.
P.S. I am aware that mesh is not good enough to produce acurate results, sole purpose of this model is to understand the setup of such a sim and have a model that can run on a small personal computer easily.
Thanks in advance.
Find more posts tagged with
acupro thanks for your suggestion. The units are indeed consistent in the model. The physical dimensions of the model are inspired from a wind turbine application, so the size of the beam (representing the blade in this case) is 30m in length. As a result, the control volume is indeed 45x25x37.5m. I kept the units as the default in acusolve and I set up the optistruct model in meters, kg, and seconds to keep it consistent with the CFD units. As a result, this should not be an issue.
Thanks again for your comment.
Altair Employeeacupro thanks for your suggestion. The units are indeed consistent in the model. The physical dimensions of the model are inspired from a wind turbine application, so the size of the beam (representing the blade in this case) is 30m in length. As a result, the control volume is indeed 45x25x37.5m. I kept the units as the default in acusolve and I set up the optistruct model in meters, kg, and seconds to keep it consistent with the CFD units. As a result, this should not be an issue.
Thanks again for your comment.
It looks as if the communication/exchange never happens - OptiStruct just runs to completion, stops - and the communication port closes, and AcuSolve pops the error and stops. Do you see the OS job running to completion - with basically nothing happening? It is likely an issue with the OS setup, but I don't know enough about OS to point to a solution. The exchange should be happening every 0.005 seconds - as that is the time increment on the AcuSolve side.
Hi Giann_k
You can try to use Altair Simlab for the set-up!
from the link below and under Fluids and Particle Dynamics / Multiphysics / you will have the same guide for "piezoelectric energy harvester"
Altair for SimLab Learning Center
/johan
Hello. I have the same issue. Did you find a solution?
Is your OptiStruct model running to completion - never exchanging with AcuSolve?
Yes, it finishes with:
acuSolve: *** ASSERTION in Function <iopWriteSock> File <iopSocket.c> Line <612>
acuSolve: *** TCP socket write error; Permission denied
acuRun: *** ERROR: error occurred executing acuSolve"
Yes, it finishes with:
acuSolve: *** ASSERTION in Function <iopWriteSock> File <iopSocket.c> Line <612>
acuSolve: *** TCP socket write error; Permission denied
acuRun: *** ERROR: error occurred executing acuSolve"
Please attach the AcuSolve .Log file. If OptiStruct runs to completion, it indicates there's an issue with the OptiStruct input file - likely no exchanges are indicated there, so it just runs to completion on its own, and the connection between AcuSolve and OptiStruct closes once OptiStruct finishes its simulation.
Are you able to attach the OptiStruct input file? Which interface did you use to generate that?
Please attach the AcuSolve .Log file. If OptiStruct runs to completion, it indicates there's an issue with the OptiStruct input file - likely no exchanges are indicated there, so it just runs to completion on its own, and the connection between AcuSolve and OptiStruct closes once OptiStruct finishes its simulation.
Are you able to attach the OptiStruct input file? Which interface did you use to generate that?
I am attaching the two input files and .Log from Acusolve as well as .out from Optistruct. I am generating the Optistruct input file with HyperMesh 2023.
I am attaching the two input files and .Log from Acusolve as well as .out from Optistruct. I am generating the Optistruct input file with HyperMesh 2023.
In the FSI card data - line 48813 of the .fem file - what happens if you specify 1 for MINEX and 10 for MAXEX rather than leaving them blank? Does that force actual exchanges? (The docs do say they can be blank to use the defaults - as you have it now - but wanted to see if actually specifying them makes it work.)
In the FSI card data - line 48813 of the .fem file - what happens if you specify 1 for MINEX and 10 for MAXEX rather than leaving them blank? Does that force actual exchanges? (The docs do say they can be blank to use the defaults - as you have it now - but wanted to see if actually specifying them makes it work.)
I have tried this and I obtain the same error.
I have tried this and I obtain the same error.
Now I see in the AcuSolve input file - the same surface set
"fsi1f.SurfaceSet_4.tria3.SolidBody_1_3.wedge6"
is used both with Simple BC "Wall" and External Code Surface. What happens if you comment (add # in front) all the lines for the Simple Boundary Condition "Wall" ? (Or remove that Wall BC if you don't want to manually edit.) Any difference?
And what if you set the initialize flow/stokes and turbulence to off? Any difference?
Are you able to attach the .hmcfd model for the AcuSolve side (compressed)?
Now I see in the AcuSolve input file - the same surface set
"fsi1f.SurfaceSet_4.tria3.SolidBody_1_3.wedge6"
is used both with Simple BC "Wall" and External Code Surface. What happens if you comment (add # in front) all the lines for the Simple Boundary Condition "Wall" ? (Or remove that Wall BC if you don't want to manually edit.) Any difference?
And what if you set the initialize flow/stokes and turbulence to off? Any difference?Are you able to attach the .hmcfd model for the AcuSolve side (compressed)?
Along with that - please indicate which version you are using - both OptiStruct and AcuSolve. (The Log file indicates AcuSolve version 2021.2 - quite old already.) We've tried to reproduce this behavior using the current release - 2023 - but cannot - so we're thinking it's a versions issue. (I even added the Simple BC for the same surface sets as the External Code Surface - and that's just ignored.) Along with supplying the AcuSolve model files as requested - please try with both solvers version 2023 - and see if that fixes things for you.
Along with that - please indicate which version you are using - both OptiStruct and AcuSolve. (The Log file indicates AcuSolve version 2021.2 - quite old already.) We've tried to reproduce this behavior using the current release - 2023 - but cannot - so we're thinking it's a versions issue. (I even added the Simple BC for the same surface sets as the External Code Surface - and that's just ignored.) Along with supplying the AcuSolve model files as requested - please try with both solvers version 2023 - and see if that fixes things for you.
Did you try this yet with both solvers at version 2023 (or at least 2022.3)? Any update? Can you attach the AcuSolve model files (input, MESH.DIR) as well?
Did you try this yet with both solvers at version 2023 (or at least 2022.3)? Any update? Can you attach the AcuSolve model files (input, MESH.DIR) as well?
At the moment I cannot get the same version for the two programs, but when I run the harvester tutorial in the two different versions it works
Are you able to attach the AcuSolve model files (input file, and mesh directory) - so we can test?
Yes, I'm attaching them
Yes, I'm attaching them
On the structural side - the plate goes from X = 4.999500e+00 to X = 5.000500e+00. However, on the CFD side - the plate goes from X = 5.000000e+00 to X = 5.001000e+00. So the CFD plate is shifted about half the thickness of the plate. I'm wondering if this might cause the problem. Please rebuild the model such that the plate for both is exactly the same - then try again. Any difference?
On the structural side - the plate goes from X = 4.999500e+00 to X = 5.000500e+00. However, on the CFD side - the plate goes from X = 5.000000e+00 to X = 5.001000e+00. So the CFD plate is shifted about half the thickness of the plate. I'm wondering if this might cause the problem. Please rebuild the model such that the plate for both is exactly the same - then try again. Any difference?
It looks like something was missing in the OptiStruct model definition. I am not an OptiStruct master, by any stretch of the imagination. I took your model into HyperMesh classic, and followed the OS-T:1600 tutorial to define things - and at least finally got the models to communicate properly. After some time steps, it looks like the OS model doesn't converge based on the specified parameters within the given time steps and max stagger iterations on the AcuSolve side. So you can adjust the OS and AS parameters as you like - but at least the codes do communicate. This was all done with 2023 - but should also work with earlier versions. I also built a finer mesh for the AcuSolve side - and adjusted the multiplier function, inlet velocity, etc - to get at least a few time steps. You'll need to adjust those also - if you really want the 8 m/s you initially had specified. Maybe the time increment also needs to be reduced. But at least you now have models that communicate.
It looks like something was missing in the OptiStruct model definition. I am not an OptiStruct master, by any stretch of the imagination. I took your model into HyperMesh classic, and followed the OS-T:1600 tutorial to define things - and at least finally got the models to communicate properly. After some time steps, it looks like the OS model doesn't converge based on the specified parameters within the given time steps and max stagger iterations on the AcuSolve side. So you can adjust the OS and AS parameters as you like - but at least the codes do communicate. This was all done with 2023 - but should also work with earlier versions. I also built a finer mesh for the AcuSolve side - and adjusted the multiplier function, inlet velocity, etc - to get at least a few time steps. You'll need to adjust those also - if you really want the 8 m/s you initially had specified. Maybe the time increment also needs to be reduced. But at least you now have models that communicate.
OK - We found the key... If you add to your original .fem file:
PARAM,LGDISP,1
before your GRID data lines, like this,
$
PARAM,LGDISP,1
$$
$$ GRID Data
$$
your original model (OS and AcuSolve) also runs and the codes communicate. You'll need to adjust the settings (probably for both codes) to avoid distortion, etc, as I indicated above - but the codes do communicate.
It looks as if the communication/exchange never happens - OptiStruct just runs to completion, stops - and the communication port closes, and AcuSolve pops the error and stops. Do you see the OS job running to completion - with basically nothing happening? It is likely an issue with the OS setup, but I don't know enough about OS to point to a solution. The exchange should be happening every 0.005 seconds - as that is the time increment on the AcuSolve side.
Does this help with your model? If you add to your original .fem file:
PARAM,LGDISP,1
before your GRID data lines, like this,
$
PARAM,LGDISP,1
$$
$$ GRID Data
$$
your original model (OS and AcuSolve) also runs and the codes communicate. You may need to adjust the settings (probably for both codes) to avoid distortion, etc - but the codes should communicate.
OK - We found the key... If you add to your original .fem file:
PARAM,LGDISP,1before your GRID data lines, like this,
$
PARAM,LGDISP,1
$$
$$ GRID Data
$$your original model (OS and AcuSolve) also runs and the codes communicate. You'll need to adjust the settings (probably for both codes) to avoid distortion, etc, as I indicated above - but the codes do communicate.
Than you very much!
Yes, the geometry, mesh, model and time steps were preliminary until I was able to communicate both models. Now it works, so I want to thank you again.
One thing to note - the size/location/units need to be consistent for both models.
I see in the CFD model, the overall domain is 45 x 25 x 37.5.
With the material properties (Air) left in MKS units - those dimensions then represent meters. Is that correct - the domain is 45 meters in X, 25 meters in Y, and 37.5 meters in Z?
If those dimensions should be mm instead, then you need to modify the material properties to be consistent with dimensions in mm.
OR - modify both models so that the dimensions are in meters, and keep consistent MKS units for materials, dimensions, boundary conditions, etc.