I’m interested in working in a floating structure where I have applied loads (forces and moments), pressure loads (hydrostatic and hydrodynamic) and accelerations (due to the rigid body motion and gravity). With these boundary conditions, the unconstrained system should be in equilibrium. My understanding is that when running a static analysis for these kind of floating systems, the inertia relief should be used. Below you can see what I’m trying to achieve:
My question is: can I somehow account for inertia relief in PrePoMax or CalculiX? If not, is there a workaround that I could use?
Thanks for the feedback. I tried using a soft spring approach and it works
However, I faced some limitations. My simple test is just a beam where I apply the gravity acceleration and one external force with the same magnitude (i.e., F = rho·V·g), but in the opposite direction. This would result in a system in equilibrium. Then I included as a constraint a point spring for all the nodes in the model. Because I have many nodes, I want to apply a very small stiffness (e.g., 1E-09 N/mm). But, unfortunately, it seems that I’m facing an issue due to the exponential notation:
If I define a bigger stiffness (e.g., 0.0001 N/mm), then the exponential notation is not used and the inputs can be interpreted by the code as expected:
Stiffness of soft springs doesn’t necessarily have to be that small. It depends on the forces in the model. In fact, discrete dashpot elements are recommended over springs when it comes to stabilizing the model. There are procedures to estimate their parameters based on convergence output in Abaqus but I don’t think you can get enough information from CalculiX so you would have to do less accurate estimates for springs or dashpots.
Can you share the file where you get the error on spring stiffness with 1E-9 N/mm. For me, it works.
If you use a surface spring, the number of nodes does not affect the spring stiffness, since it is distributed to the nodes to achieve the same total stiffness.
The problem is not that the number is small, but that in the CalculiX .inp file it is written as 1E-9 and CalculiX does not read such number correctly. I added a decimal separator after the integer value so now it is written as 1.E-9 and it works.
Don’t you think it would be a good idea to review this criterion for the real inputs?
Manual mentions explicitly about this point.
“user should painstakingly take care that any real numbers (spring constant, spring force, elongation, temperature) contain a decimal point (“.”, which is a good practice anyway).
I comment because some rules are not so gentle and don’t deliver an error message when omited.
Thanks for the feedback! Just to make it clear: if I write in the PrePoMax interface 0.00001 N/mm, the program will convert it automatically to 1E-05 N/mm and crash when trying to interpret it later on. The same holds true if the user writes 1.0E-5 N/mm or 1.E-5 N/mm. PrePoMax converts it automatically to 1E-5 N/mm and will crash. One work around to make it work is for example writing 1.1E-5 N/mm.
In the code, a special function is used every time a real value is saved to Calculix due to other CalculiX limitations. This function wrongly identified 1E-9 and added a decimal separator at the end of the value. So it acctially wrote 1E-9. with the . at the end. I fixed it now so I think it should also work for other Calculix features.
