Best Of

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.

Hello,

The recommended values for shell element properties are the ones that you have inserted already.

As for the material, it is suggested to use /MAT/LAW2 instead of /MAT/LAW1, because it can produce more accurate stress distribution through the thickness.  To use this law for elastic only material you have to set the Yield Stress equal to a high value that is not reached (1e+30 is proposed).   /MAT/LAW1 uses global integration only, one integration point, which is less accurate.

Finally, you can use thick shell elements, which are preferred for higher accuracy in stress distribution through thickness.  When you use Thick Solid elements it is recommended to insert the /H3D/NODA/GPS and /H3D/NODA/GPSTRAIN engine file outputs that will let you see the results for stress and strain in the outer nodes (that might be higher).

Additionally, you must be careful with the results you display.  For example, different Averaging Methods in Contours can include or not the precise values on nodes and may give only an average value.  In the following images you can see the same element contour without and with an Averaging Method.  This can lead to a change in the displayed maximum value (see images).

Hello Angelica, thank you for your comment. 

Before answering, I must ask which standard you compare your hand calculations to. 

S-LINE has different ways of the longitudinal spacing for bars depending on the code selected, find a short description of them below:

For ACI

For BS8110 and CP65

And CSA

As you can see, the method varies slightly from code to code, however, I hope that with this information you can compare accordingly to your calculations and your question is answered. 

Best regards, 

Tayen Aguilar

Thanks Tayen, I'm comparing with CSA.

 

Do you have any more insight into how S-LINE calculates the actual bar spacing it compares to the CSA code?

Hi Angelica, I would advise you to check S-LINE's help system, got to Help-->Content and you will find the Topics dialogue where you can type in the topic that you need more information about and look at the different topics, like the CSA provisions, where I got the screenshot I shared earlier. 

If you have any additional questions, please be welcome to send them as a case to hwsupport@altair.com along with any models you would like us to look at. 

Best, 

Tayen Aguilar