Stuck? 
support@mecway.com
support@mecway.com
Mecway
FEA
Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
support@mecway.com
FEA
It looks like you're new here. If you want to get involved, click one of these buttons!
Comments
@JohnM quite right about too much fun!
Grandson voted for a Lego tractor drop -- if you are taking requests.
But real question- "real" Legos have that wonderful click that preloads them into place. Is there a way to create this in openradioss? In other words, like a bearing installed in a block and then dropped on the ground to see if it will pop out.
Or perhaps use a beam for the stud and make the contact between its nodes and the anti-stud. Then I think you can define the gap size in the interfaces, which would be the stud radius so it's perfectly circular - or at least a string of overlapping spheres.
If yes, are there any special formatting issues? or other things I should be aware of?
If not, how could I still manage such a simulation using Mecway as pre-/postprocessor?
https://2025.help.altair.com/2025/hwsolvers/rad/topics/solvers/rad/tensile_test_example_r.htm
with help of the following:
https://openradioss.atlassian.net/wiki/spaces/OPENRADIOSS/pages/24444938/Tensile+Test+Example+Tutorial+Using+Gmsh
I created a 'OpenRadioss' custom material profile, according to what is explained in the Radioss manual:
https://2021.help.altair.com/2021.2/hwsolvers/rad/topics/solvers/rad/block_elastoplastic_materials_r.htm
Not all outputs could be selected from within Mecway, by using the OpenRadioss 'custom enginer input', this could be solved as well. Syntax is explained in the radioss manual:
https://2021.help.altair.com/2021/hwsolvers/rad/topics/solvers/rad/animation_post_process_output_files_engine_r.htm
Results:
I downloaded the starter and engine exe files and have pointed Mecway to the paths as follows:
Starter:
C:\Users\ericw\Documents\Mecway\OpenRadioss_win64\OpenRadioss\exec\exec\starter_win64.exe
Engine:
C:\Users\ericw\Documents\Mecway\OpenRadioss_win64\OpenRadioss\exec\exec\engine_win64.exe
When I try to solve the model the following error appears:
Cannot Run Starter
C:\Users\ericw\Documents\Mecway\OpenRadioss_win64\OpenRadioss\exec\exec\starter_win64.exe
Can anyone help me understand why this is happening.
Thanks!
RAD_CFG_PATH=C:\Users\ericw\Documents\Mecway\OpenRadioss_win64\OpenRadioss\exec\hm_cfg_files
RAD_H3D_PATH=C:\Users\ericw\Documents\Mecway\OpenRadioss_win64\OpenRadioss\exec\extlib\h3d\lib\win64
KMP_STACKSIZE=400m
PATH=C:\Users\ericw\Documents\Mecway\OpenRadioss_win64\OpenRadioss\exec\extlib\hm_reader\win64;C:\Users\ericw\Documents\Mecway\OpenRadioss_win64\OpenRadioss\exec\extlib\intelOneAPI_runtime\win64
Just a guess but the Reference Guide says /INTER/TYPE7 has small time step with small gap and the gap seems to be the default Gap_min which says
Does that suggest any extreme small values?
I'm about to start a project of simulating a crash of a sheet metal structure using OpenRadioss after having wasted a week and a half with not succeeding in doing it with Calculix. I intend to use shell elements but is it correctly seen that OpenRadioss doesn't export stresses for shell elements and doesn't export strain at all? It feels a bit like I'm going to be working blinded if I don't have that information when I have to use the simulation for designing the part to have the wanted reaction forces.
It does output shell stress and strain but Mecway currently doesn't have those in the GUI (some will be in version 29). You can include them for element values easily though. Add some keywords to OpenRadioss -> Custom engine input in Mecway. Eg:
/ANIM/SHELL/VONM von Mises stress, probably at the midsurface
/ANIM/SHELL/TENS/STRESS/UPPER stress tensor components at upper surface
See the Altair Radioss Reference Guide for all the options.
I'm encountering some errors that I don't understand though.
I'm trying to crush a box and want to get it to do simple stuff before I make the model more complicated by adding contacts and geometry until it is a proper crash simulation.
The box is fixed in one end but if I don't have any other loads, then I get the errors
"ERROR ID : 156 ** ERROR IN FUNCTION READ
** ERROR: FILE openradioss_test_0000_0001.rst NOT FOUND "
If I add a force or a velocity to the end (blue in the screenshot), then it will run like that but I don't undstand why it won't run if there's nothing.
For now, suppress or delete the Custom model definition until it's got some content.
I think I have the model set up as it collapses sort of as expected and I can read out the force from the impactor.
I'm still a bit confused as to why it reports the warning "incompatible kinematic conditions in model" but still finishes. Also, box in the lower left corner states that the end time is 0,013991 seconds although I asked to run until 0,014s, but it is probably OK as the results state that the time in the last result is 0,014s.
I'm super exited that OpenRadioss has a library of material properties that include Aluminum 6082-T6, but I still have to check if those properties matches the tensile tests we have made ourselves.
Apart from the material data, the only thing left is "just" to create the geometry of our actual crashbox.
Not surprisingly, it wasn't any success to just take the model I had prepared for CCX including bend reliefs and what not. OpenRadioss estimated 157 days of computing time (hurray for estimated computing times!) and then crapped out after an hour, stating that the timestep was negative.
** INCOMPATIBLE KINEMATIC CONDITIONS IN MODELcan be serious because it sometimes means constraints are not being enforced. In this case, it's an interaction between the imposed X velocity of the moving plate and the Y and Z displacement constraints on the same 4 nodes. I think it's harmless because Altair says "Radioss Starter does not check if the kinematic conditions are really incompatible. If they are strictly orthogonal, or if they are not applied simultaneously, just ignore the warning." and here they are orthogonal.It's normal that the final time step is slightly less than what you request. I think this is because the time steps it outputs may be just the nearest internal time steps which don't have nice round values.
If you're having trouble with too-small time steps, you can look at the element time step solution variable to see which elements have the smallest time step and slowing the whole thing down.
An important observation that the contacts can artificially stiffen the structure. It was solved by switching which was the master and which was the slave. If the slave surface was the larger surface, then it was artificially stiffened. The screenshots below show the wierdness that can be seen in the von mises stress plots if the contacts stiffen the structure.
Also, in the incorrect analysis, the monitor would read out a large percentage as the error, while the normal-looking simulation reads out a smaller number.
I do have one question, that I'd like others to weigh in on: On this model, I have only half of the box and have a frictionless support on the edges that lie on the symmetry plane as this is how I would do it in a static analysis. Is this simplification still reasonable for an explicit nonlinear dynamic response analysis or does it suppress something important?
The deformations does look realistic to me.
Incorrect and artificially stiffened:
Normal-looking simulation results:
@Sebastianmaklary
Non-linear Buckling involve out of plane displacements. If you impose symmetry BC you are removing that possibility. In your video one can see how the box buckles crossing the initial symmetry plane althought the piece is completely symmetric.
Imagine the box is an I beam section under compresion. A simmetry BC in the weak axis would remove the first buckling mode stiffening the model considerably.
Thank you for that input. It does make sense that the structure will be stiffer if some deformation modes are suppressed by the imposed symmetry, so this morning, I tested it by running the same geometry as a half model and a full model.
The half model had a peak of 82,5 kN at 0,00029s while the full model peaked earlier with 171 kN at 0,00014s. Since the full model is (within reasonable margin of error) twice as much as the half model, I think that it is reasonable to use the half-model for iterating the design faster. The full model takes 2-3 times as long to run as the half model and also takes longer to setup as there are more contact surfaces to click.
But I guess I'll have to run full models occationally, when I have the loads of the initial peak reduced to where I want to and are ready to simulate more of the deformation.