Best Of

Hi Sudip,

Some of these results will require the creation of new events and manual calculation.

1. Roll Stiffness - This is a SDF output, and can be seen after generating a standard report after the completion of a half-car Static Roll Analysis. Roll rates can then be seen on Page 12: Roll - Roll Rate, Tramp Rate. The slopes of the curves will determine the roll rate of choice.
2. Vertical Stiffness - This is also an SDF output, and can be seen after generating a standard report after the completion of a half-car Static Ride Analysis. Vertical Stiffness can then be seen as the slope of the curves on Page 7: Ride Test - Vertical Force vs. Wheel Travel.
3. Turning Circle Diameter - This will require the creation of an event, like the Road Course, where the steering angle is increased via a Motion entity until the steering limits are reached (specific to your vehicle). Make sure to complete the event at low speed. Measure the displacement of the vehicle using a marker, usually attached to the front outer wheel center (if no bodywork available) or the outer front corner (if bodywork available).
4. Suspension Frequency - If this is referring to suspension natural frequencies, then you will need to complete a modal analysis. Normally this is done as a half-car model, so there is no interference from the opposing suspension components. Run a Linear analysis on the half-car model and then review the Modes until you come upon the mode of interest. For example, in the GIF below, this would be the ride frequency for this half-car model:
   1. Note - the displacements are always exaggerated, so this is not a realistic visual of the ride mode. 
5. Roll Gradient - This is typically calculated during a constant radius lateral acceleration event, at different speeds. The body roll angle is then divided by the vehicle lateral acceleration to get the roll gradient. 

Hope this helps!

Adam Reid

Hi Brian
You have some severe penetration in your model which will make your model hard to converge. Overlap can be modelled and need to resolved prior to rotation.

Here is and interference fit model:

OS-V: 0280 Axisymmetric Elements - Interference Fit Between Two Cylinders (altair.com)

And here is a case of large sliding

OS-E: 0160 Nonlinear Static Analysis of Snap Fit Assembly Using Continuous Sliding (altair.com)

Be careful with meshing, it is good to coarsen the mesh out to reduce model size!

For initial set-up, you can also consider to just model 1-2 threads!

/Johan

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).