Determine Equivalent Static Loads in RADIOSS
Hi,
I am wondering if there is any known way to extract the dynamic loads produced by high velocity interactions and convert them to static loads. For example, for a ball hitting a wall, I would like to determine the loads produced on the wall through the ball hitting it and produce an equivalent static case in OptiStruct. As far as I can tell, this is done by using RADIOSS optimization, but I would prefer to only get the loads and not necessarily optimize the part itself.
Edit: More specifically, it seems the load case is an XSTEP. Can anyone help me find where this data is stored and how to simply apply it to an OptiStruct model.
Thanks!
Answers
-
Hello,
Alternatively, I am wondering why it is that the RADIOSS optimization process gives the results below. It seems that all elements are treated as one design variable rather than each their own. I was hoping I would be able to get a topology for an optimized structure with a map of element densities. Is there something wrong with my radopt?
0 -
Hi,
to extract the contact loads from Radioss simulation and use them for Optistruct optimization follow the procedure from the attached reference (page 32):
- Identify the time of contact force peaks by requesting /TH/INTER contact interface output block and postprocessing in Hypergraph.
- Define /ANIM/VECT/CONT output request and query the contact forces on nodes of interest at the time of contact force peaks in Hyperview. Export the data in csv file format.
- Import the contact forces in Optistruct by Analysis>forces>linear interploation>file
As discussed before, the element size in the region of interest should be 5-10mm. Using such refined mesh on the structure as big as the railcar will be computationally expensive in terms of CPU. If we only want to extract contact forces (using the above procedure) and assuming the walls of railcar are not deforming we can put a rigid body on it so the timestep is not penalized by the small mesh size anymore and only SPH and contact interface will dictate the timestep. Optimization could then be performed in Optistruct using refined mesh with finer contact force resolution- this could be computationally expensive in terms of RAM.
I am not at my Hyperworkstation to check your model, but I can offer the following observations based on shared input decks:
- Stress constraint is not recommended in the design concept stage: topology, topography and free-size optimization. The stress constraint definition in a topology optimization is a global constraint and does not target local stress concentrations. These areas can be addressed subsequently through size, shape, and free shape optimization or a combination thereof. Artificial stress concentrations are filtered out during topology optimization with stress constraints. These include regions around rigid connections, concentrations due to hard geometric features such as corners, etc. Stress constraints for a partial domain of the structure are not allowed because they often create an ill-posed optimization problem since the elimination of the partial domain would remove all stress constraints. Consequently, global stress constraint applies to the entire model when active, including both design and non-design regions. Stress constraints may not work well in a model where there is a large differential in response values between design and non-design spaces. In these cases, it is recommended to modify the problem formulation to say, compliance-based for example. It is not recommended to use the global stress constraint along with a mass/volume constraint. The constrained mass/volume may not allow the stress constraint to be satisfied. Unless mesh is stress converged then the stress constraint should not be relied upon.
- Instead of minimize weight subject to displacement and stress constraints try to minimize compliance subject to volume fraction or mass constraint.
0 -
Altair Forum User said:
As discussed before, the element size in the region of interest should be 5-10mm. Using such refined mesh on the structure as big as the railcar will be computationally expensive in terms of CPU. If we only want to extract contact forces (using the above procedure) and assuming the walls of railcar are not deforming we can put a rigid body on it so the timestep is not penalized by the small mesh size anymore and only SPH and contact interface will dictate the timestep. Optimization could then be performed in Optistruct using refined mesh with finer contact force resolution- this could be computationally expensive in terms of RAM.
Hi,
Thank you very much for your help with this. I'm looking at following this advice as it would be a good way to reduce computation time, but wouldn't making the walls rigid result in highly inaccurate forces? Doesn't the stiffness play a role in determining the forces?
Edit: I found that in OptiStruct, you can model as a flexible body as well as a rigid using the Craig Bampton method. Is this possible in RADIOSS as well?
0 -
Hi,
the reasoning behind the assumption that making the walls rigid will not affect the contact forces significantly because:
- the walls are not deforming too much to alter the orientation or induce stress stiffening
- the contact stiffness is taken from material properties, according to Istf flag
As a consequence of this assumption, it is expected the contact forces due to rigid mesh will only be slightly off the results from the deformable mesh. However, this technique enables extracting better force resolution on a finer mesh, ultimately improving the stress distribution. I won't be able to qualify the validity of this approach myself until next week.
While it is possible to use flexible bodies in Radioss, I am not sure if flexible bodies will deform on contact.
0 -
Hi,
The assumption of a rigid body on the walls is not valid, because a high acceleration lateral load (5g) considerably deforms the structure. As can be seen in the image below, the resultant contact forces are nearly equivalent during gravity loading but diverge significantly during lateral acceleration.
<?xml version="1.0" encoding="UTF-8"?>
Below is a comparison (by normalization) between rigid/deformable and deformable AMS/deformable. It can be observed that rigid model overpredicts 3x on spikes and underpredicts 0.5x during peak response. The AMS overpredicts by 1.25x and follows the trend more consistently. The AMS was run with the timestep of SPH elements (3e-5).
<?xml version="1.0" encoding="UTF-8"?>
Below is a plot of resultant contact forces and strain energy of components designated for optimization. The peak response occurs at 0.175s so there is no need to run the model for 2.2s during optimization. ESLM needs to capture the peak responses of interest (in case of compliance it is strain energy) and it evaluates only the animation output timesteps. Therefore reduce the total run time and increase the animation output frequency, as the peak response might shift during optimization.
<?xml version="1.0" encoding="UTF-8"?>
There are some other concerns:
- the 5g lateral acceleration is more consistent with F1 car than hopper wagon
- the lateral load is applied from 0.1s, before the cargo is settled under gravity (it takes approximately 0.5s with /KEREL)
0 -
Hyperman,
Isn't the load calculated as:
With a function value of 9.81 and an FSCALE of -1, I should get an acceleration of -9.81 m/s2 down, and similarily I should get 5 m/s2 lateral, no?
I was not aware that the settling was necessary however it does make sense that it should. The peak response occurs at 0.175 sec because the gravity initially drops the SPH particles onto the hopper, which I have not been able to fix as of yet. The dropping creates the high load you see at 0.175 seconds, which is not of interest as this is a software limitation and not a realistic load. The main interest is the lateral load on the walls. If the particles do not settle until 0.5 seconds, I must run it for at least that.
Regardless, I have found some more computing power I can use and am getting results soon. I will share here once I get them for the sake of learning for other people.
0 -
Hi,
my bad, sorry for the confusion- the lateral acceleration was 5 m/s2 indeed.
Consider splitting the simulation into two parts (otherwise kinetic relaxation will be applied throughout):
- 1st engine file: settling under gravity with /KEREL for about 0.5s
- 2nd engine file: lateral loading till peak response + 0.1 or 0.2s margin
Looking forward to hearing about the results.
0 -
Hi,
Thank you for the interesting suggestion - I'm testing it out as we speak. I wanted to try running it for the simple case of ditching from the demos. I split it into two engine files, with the first running for 1 ms and the second running for the remaining 39 seconds. What happens is I get an increase in energy error by 1% when the second run begins. Is there a reason that this happens? I have not applied /KEREL nor /AMS
I followed this tutorial:
Also, for running with KEREL in one part and AMS in the other, there is /AMS in the starter file. Do I need to make two different starter files for each engine?
0 -
Hi,
the first run ended with the -0.7% energy error and the second run starts from 0% energy error. The energy error is reset to zero on restart so there is actually no energy increase. To restart from the previous energy balance a *.ctl file should be created with /STOP defined (similar to the checkpoint CHKPT command in Radioss Solver Run Manager).
https://community.altair.com/community?id=community_question&sys_id=75860c3a1b2bd0908017dc61ec4bcbe4The /AMS in the starter is used to declare components on which AMS is applied and is defined only once.
/KEREL is applied in the engine file.
0 -
Update: recent simulations show it was - as usual - likely my gapmin value. Still concerned about the contact forces being too concentrated in one location. Shouldn't they be distributed?
Hi,
I ran the simulations over the course of the weekend. I cannot upload them in full, however it didn't seem to go well. I'm not really sure why, however the movement of the particles is a little too 'Brownian,' and for some reason affecting a lot the roof of the car with minimal contact. I double checked to make sure the particles are not accelerating upwards by accident, and they are not. More concerning, however, is that the contact forces are only registering on certain points along the structure (third .gif). Any suggestions as to what may be wrong? I set up and am in the process of running a new simulation with much less SPH elements, as I tried your suggestion on my coarser model and it is working just fine and relatively accurate. I am not sure what the problem is...
Thanks in advance. I realize I've asked for a lot so far and really appreciate the help.
0 -
Hi,
there are some modeling errors:
- check elements(F10)>1D>duplicates: there are some duplicate beam elements
- tools>find connectivity: the Undercarriage beams are not connected with the rest of the model. Equivalence the nodes in edges panel (shift+F3).
You should reconsider the boundary conditions. There are point supports which cause stress singularities (as the mesh is refined, the stress and strain energy will tend to infinity) and even worse- displacement singularity (displacements will also increase with refinement). Constrain a cluster of nodes to avoid this issue. Consider how the hopper wagon is constrained in real life- the model is only constrained with 4x point support on one end and rely on XZ plane symmetry to constrain the other end. As a result, the wagon is lifting vertically in the symmetry plane. Gravity and lateral loads should probably be applied to the whole model, not just SPH.
The lateral load was ramped up during settling under gravity stage when kinetic relaxations was still active. It should be ramped up only after this stage instead. I have no explanation about the 'Brownian motion', but when I ran settling under gravity it was well behaved.
<?xml version="1.0" encoding="UTF-8"?>
The contact forces are actually distributed, but you are only seeing the peaks as the legend contours according to the max value. Contour panel>legend>edit legend...>type:dynamic scale or input small number in the max field.
<?xml version="1.0" encoding="UTF-8"?>
The coarse mesh is stiffer so it is normal to see more deformation with finer mesh. My guess (without h3d it's hard to tell) for the roof is the frame beams are deforming (coming together in the Y direction) imparting compressive forces to the roof which is buckling elastically. This may be because the undercarriage beams were not connected. Use the deformed shape scale factor to magnify deformations. Consider if the beam layout should also be optimized.
The interface is controlling the timestep in the 2nd run, which may be due to too high AMS imposed timestep. Output the number of AMS iterations per cycle via /DT/AMS/Iflag=2 which may help monitoring convergence quality at no extra CPU cost. Maximum allowed iterations before the divergence stops is 1000. 75 to 100 iteration per cycle is a sign of a poor convergence, 50 still may provide some speedup and 30 iterations or less is considered a good convergence.
0
