Hi! I must say that PrePoMax for me was love at first sight. I really like the way it was implemented. For me if it was possible, I would use PrePoMax for all my simulations. But unfortunately, I could not use PrePoMax in none of my simulations yet. The reason is simple. I work with hydroelectric and dam projects and all my simulations envolves variable pressure on surfaces like hydrostatic pressure, earth pressure, under pressure and so on. I think this is an important feature for a FE software, so I would like to left here “my big wish” for next versions of PrePoMax. Better would be if the implementation could use formulas/expression to define the value of pressure in any point of surface based on x, y and z coordinates of the point. This would be really fantastic! I think tis feature would be very useful not only for me but for many PrePoMax’s users.
My second wish for PrePoMax, is at the same way, be possible to also define thickness for shell elements as a function of x, y and z coordinates.
I was just going to add that. Hydrostatic pressure is one of the most common feature requests, many users asked about it. CalculiX itself doesn’t have this type of load implemented in keywords and it’s necessary to use the dload.f subroutine (even the documentation mentions hydrostatic pressure as an example for use of this subroutine). However, a preprocessor such as PrePoMax could have this implemented in the form of equivalent nodal forces (pressure function numerically integrated over the area of the surface). It would be nice to have the support for general non-uniform pressure loads but hydrostatic pressure type would be a great start too. The user would likely have to specify the magnitude, zero pressure height and reference pressure height (at which the specified magnitude occurs).
When it comes to variable shell thickness, CalculiX has this implemented (*NODAL THICKNESS keyword) so workarounds won’t be necessary, unlike for the non-uniform pressure.
non uniform loads are common in application, mostly in linear slope distribution. could be from fluid, earth pressure or both. convert these load to point loads by integration is required to properly assign an equivalent loads. may the load is averaging to uniform since CalculiX only accept this type, but result become less accurate.
output based on CFD result also frequently used by many simulation . the input format is in coordinate (x,y,z) and total pressure (force/area). the pressure maps can be highly non uniform.
regarding to non-uniform thickness of shell element it seems can be useful feature also. keyword of *Nodal Thickness is required to assign for each node in whole mesh. it will be overwrites the thickness were previously defined in *Shell section keyword.
This is indeed a useful feature and it is already on the internal to-do list. I think that a more general approach could be some kind of distribution feature. It could first be defined based on equations or discrete points (defining it using x,y,z data points requires some kind of interpolation) and then applied to other features, like pressure or shell thickness.
Equation-based approach is quite common in FEA world, but not easy to use especially in big industrial models. Due to this reason one or two most frequently used load distributions should be available in the simplified form. One of such frequently used types of load in mechanical engineering is bearing pressure (used to define contact pressure between cylindrical surfaces). For this type of load a user should define only the total load and a cylindrical surface where it is applied.
For more general types of load I propose to use old and good approach used in ADINA. If the distributed pressure is applied to a rectangular surface, a user should input either 4 pressure values at the corners of the surface or 8 values at the corners and midpoints of the surface edges + 1 in the center of the surface (in total, a matrix of 9 values, 3x3). In the first case polyliniarly distributed pressure will be generated (as shape functions for the Q4 element), in the second case - biquadratically distributed pressure (like shape functions in the Q9 element).
Hi @Matej! Good news! It is already on the internal to-do list! I suggested based equation definition, only because I thought it was much simpler and easier to be implemented using eval functions (C#). Of course, the discrete points and interpolation is much more easier for the user. I have been use equations in Macway and interpolation in Inventor Nastran. Interpolation is far way easier and free from error in equation definition! So, if you think interpolation can be implemented, this approach of course, would be much better!
Thank you!
I would follow the general approach used in Abaqus here:
hydrostatic pressure as a predefined load type (since it’s so common and defining it via equation would require some manipulations with the model’s coordinates)
additional functionality to define the spatial variation of loads and e.g. shell thicknesses based on:
a) equations (“expression fields”)
b) x,y,z data points (“mapped fields”)
Unfortunately, CalculiX’s support for the *DISTRIBUTION keyword is limited to local coordinate systems.
even i’m not ADINA user, still can understand the workflow and what’s expected should be. also it’s possible to apply in local or global coordinate system.
may additional option to defining of input 2 pressure value is available, required to input non-uniform load of an edge shell, plane stress/strain, axisymsolid or line of beam element further.
*edited, add some sketch of example (some possibility)
First of all thanks to PPM for providing a wealth of capabilities．I am very interested in this function, I often need to transfer CFD data to a structure FEM, usually the mesh of CFD is denser than that of solid FEM, so an interpolation function is also required.
In addition, I did not find the local coordinate system in PPM, which is very inconvenient for defining displacement constraints. especially for an angular constraint . thanks
I would love to see an hydrostatic load feature too. It’s useful for those analysing tanks or silos that hold materials that behave with fluid properties.
In other software, you typically just input your fluid density, free surface location and maximum pressure surface. Obviously gravity has to be enabled.
I am working on the implementation of the variable pressure load. First of all, I will follow the proposition given by the @FEAnalyst and implement the hydrostatic pressure load. Here I do not like the Abaqus implementation of it, where the hydrostatic pressure increases only in the z-direction, and other directions can not be defined (or am I wrong).
So I was thinking of the following way to define the hydrostatic pressure load. The user will have to supply the information for the direction of the pressure increase and coordinates of two points (by selection or user entry) and their pressures. So that combines for 3 x 3 + 2 = 11 data values. Is that too much? Is there an easier way?
Then I will be able to compute the pressure for any combination of coordinates. I will determine the pressures in the nodes, use element interpolation functions to determine the pressure distribution on each loaded element face and from that, determine the equivalent nodal forces (by integration of the interpolation functions over the element face). Then compute the element normals in nodes and add nodal force contributions from all elements to the common node.
What about forcing the user to define a gravity load (with direction), and then use this direction for the hidraulic pressure definition? And about the two pressure values… if the user just define a point (coordinates or picking a node) on the free surfaces of the fluid cannot be directly computed?
That’s right, I also don’t like such limitations that force you to use particular axes.
This seems to be a good option. Input for a hydrostatic load will require defining a few things anyway. The approach that you described sounds very reasonable.
I wouldn’t go this way. It’s not always desired to use gravity load too. Especially since the hydrostatic load option could also serve as a general triangular (or trapezoidal) distributed load, not associated with the presence of a fluid.
I can check how it works in other software apart from Abaqus.
Maybe is not general, but is by far the more logical for the hydrostatic load defintion, maybe you could have a more advacend feature for triangular or trapezoidal loads.
Other software and what you have to specify there to define the hydrostatic pressure:
Ansys:
fluid density
hydrostatic acceleration vector (mm/s^2)
free surface location (x,y,z coordinates)
Mecway:
a point on the free surface
fluid density
gravity load
general variable pressure load is also supported (function with coordinates)
Simscale - general variable pressure load:
a formula using coordinates or a table with coordinates vs pressure
I like the approach used in Abaqus, apart from that axis restriction. The possibility to define the hydrostatic pressure by two values (at both ends) could be a good option. Gravity load may help with hydrostatic pressure definition but is not always desired since it affects the whole response of the model and can make the verification of results more challenging. What’s more, in Abaqus gravity load is known as the common source of issues so I’m pretty sure that it might be also the case in CalculiX.
I also think that it will be better to have separate features for hydrostatic pressure and general spatially-varying pressure. The latter could be defined using a formula but maybe also on a point-by-point basis, like in Abaqus.
Thank you both for exploring the other options. I like the idea of specifying the equation for a general pressure application. But I agree that a more specific load is usually necessary - a hydrostatic pressure.
Ansys - I don’t like the idea of specifying the density.
Mecway - I don’t like the idea of determining a free surface. It might be far away when a trapezoidal load is used.
So for now I will try to do it using two points with coordinates and their pressures and the direction of the pressure increase.
Some good news. I have added the support for the hydrostatic pressure load. I have tested it for all supported FE types and I think it works as it should. The UI is shown in the attached figure.
Now I have three user related questions.
Should the Pressure magnitude fields be positioned as they are (together after the specification of the coordinates) or rather each one separately under its coordinates (this makes more sense).
The pressure direction, at the moment, is used to define the pressure direction/depth. At the moment the orientation of this vector is irrelevant (vector 0,0,1 gives the same results as vector 0,0,-1) since linear pressure distribution is computed based on the pressure magnitudes of two selected points. So that might be confusing for the end-user. Is there any idea of how to reduce this confusion?
The representation of the hydrostatic pressure - its symbol, is also shown in the figure. What bothers meat at the moment is that when I scale the arrow symbols based on the pressure magnitude the whole arrows get very small for small pressure. Maybe I should only scale the length of the arrows in order for them to have better visibility. Any other ideas (I cannot use the colors for the representation of the magnitude).
I would rather choose the second option. It will be more intuitive.
Maybe a short note (that negative values don’t change anything) when one of these fields is selected would be enough.
By the way, would it be possible to add also „By selection” option to Pressure direction ? So that an edge could be selected when the model is not aligned with global axes.
Scaling just the length of the arrows without affecting the arrowheads seems to be a good idea.
