Jump to content


  • Content Count

  • Joined

  • Last visited

1 Follower

About Crashphys

  • Rank
    Advanced User

Profile Information

  • Country
  • Are you University user?

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 1.0e-8g is really, really small and likely what is causing issues though. Realistically, a particle of dust weight about 7.5e-7 g, so whatever your SPH particle is, it is a tenth of the mass of a dust particle. Consider whether you need this dense of an SPH mesh.
  2. 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. Refined_AMS_0002.rad Refined_AMS_0000.out Refined_AMS_0001.out Refined_AMS_0002.out Refined_AMS_0001.rad Refined_AMS_0000.rad
  3. 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? SPH_MonoDomain_0000.rad SPH_MonoDomain_0001.out SPH_MonoDomain_0001.rad SPH_MonoDomain_0002.out SPH_MonoDomain_0002.rad
  4. 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.
  5. Hi, I ran the solver with the rigid applied, however I found that the time step is rapidly degenerating. My time step is 3.7366041328229E-05 for the SPH according to the output file, and the model begins with a time step of approx 1e-4, which is definitely not consistent. The time step keeps reducing lower and lower, and by the 5th cycle is triple the initial starting time. I realise I drastically increased the number of elements, however this degeneration seems to happen regardless of element size. Anyone have any suggestions? Thanks in advance. Rigid_0000.rad Rigid_0001.rad CoarseRigid_0000.rad CoarseRigid_0001.rad
  6. HI, I'm trying to find anything I can that can reduce simulation time further. DT/NODA/CST is effective, however AMS has proven to be incredibly unstable, and the multi domain technique does not work for my application. Is there any way to perform any other model order reduction?
  7. I ran the attached demo from taken straight from the directory and got the following error: ERROR ID : 629 ** ERROR WITH EIGENPROBLEM DEFINITION AND SPMD CALCULATIONS DESCRIPTION : -- EIG ID : 1 -- EIG TITLE : Eig 1 NUMBER OF NODES FOR EIGENPROBLEMS MUST BE EQUAL TO THE TOTAL NUMBER OF NODES NUMBER OF NODES FOR EIGENPROBLEM 14354 : 24731 TOTAL NUMBER OF NODES : 0 Can someone explain what is wrong? TRUCK_EIG_0000.out TRUCK_EIG_0000.rad TRUCK_EIG_0001.rad
  8. 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?
  9. Hi, I found that the best solution might be to extract interface forces and import them to OptiStruct to do either explicit dynamic or a linear static. I have an output request for the contact forces, however I was wondering how I can get the raw data rather than a graph? Edit: I was also wondering if you could specify: is your recommendation to get the interface loads and run OptiStruct EXPDYN? I thought EXPDYN runs already with the ESLMO method? Thanks
  10. Both suggestions were incredibly helpful. I reduced the element size by one half and defined FAIL/TENSSTRAIN as recommended. Simulation runs exactly as expected now, with results showing something more realistic.
  11. Hi, I'm wondering if it's possible to run an optimization to minimize compliance rather than mass in RADIOSS. Should the objective be to minimize strain energy instead in this case? Also, there seems to be a very limited selection of responses. Is there anything for center of gravity like in OptiStruct? Thanks in advance.
  12. I have noticed in various simulations that viscosity can cause your simulation to experience a great deal of energy error. For example, in the two simulations I have attached, the only thing I changed with linear and quadratic bulk viscosity from 2.0 and 1.0 to 2e-30 and 1e-30. In the HighVisc solution, I get proper results. For low visc, there is a sharp decline in energy error and the simulation breaks. You can see the sharp decline in energy error immediately after the first cycle. Can anyone explain why this happens and how to counter it? LowVisc_0000.rad LowVisc_0001.rad HighVisc_0000.rad HighVisc_0001.rad
  13. It will be helpful if you share your model. In RADIOSS, you cannot connect an element of any type to the master node of a rigid set. The nodes that the beam3n are connected to are the master nodes for the rigid set defined by the slave nodes at the edges of your square holes. You connected a beam3n to those master nodes, which caused the error. I believe if you use another RBODY to connect the two nodes rather than a beam, your simulation will run. RBE2 is the optistruct version of a rigid connector, which is effectively the same as RBODY in OptiStruct. Watch the video here from 2:10 onwards to see how to manually create a bolt. https://www.youtube.com/watch?v=zwNIfNfaPWg
  14. 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? HopperOpt_0001.rad HopperOpt_0000.rad HopperOpt.radopt
  15. Hi, I have two blocks colliding at 200 m/s. The impact causes an insane deformation in the solids, which doesn't make any sense. When I set the velocity low to about 10 m/s, I get something reasonable. I'm wondering how I can simulate for high velocities? Collision_0000.rad Collision_0001.rad
  • Create New...