Best Of

Dear Adriano A. Koga,

Thank you very much for your reply.

I have added a tensor of strain card which is shown as follows.

 

Also requested plotting for the top layer as follows 

But results are not in order

kindly suggest any correction.

Regards ,

Sachin 

correlation is not so simple, but as a remark the paper shows probably principal strains and not vonMises, as you're plotting. The paper results shows negative strain values, which would not happen plotting vonMises.

Anyway, the red curve seems to be very high. The others are showing strains around 5000~10000microstrains, which is not so far from the paper, apparently.

Could you share the reference paper?

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.