Forum Replies Created
-
Posts
-
It seems that there are some small differences between both API. For example, in the newer Python API the elemsNumber property returns a string while in the earlier API returns an integer. Or, at least, that seems to me. But that is not a big problem, because we can convert easily a string into an integer and vice versa in Python.
Thank you so much! That solved the problem!
I used this very simple example to test the possibility of importing a mesh generated by Gmsh into NexFEM. In other more complicated cases, this possibility is very useful. Once more, thank you so much for your help and very quick support!
PS: It would be great to have an API method like setShellLocalAxes() to align local axes in a Python script.
I understood your response. So, I run again the model with a zero Poisson coefficient (turning strains in both directions independent from each other) and got the same high result (sxx = 11805 kN/m2). So, the question seems a bit more complicated. I’m not an expert on FEM, but, perhaps it has to do with the shape functions, as you said. Thanks for your time spent on this.
Many thanks for your help. Ok, it makes sense that for shell elements NextFEM applies uniform temperature gradient simultaneously in both local directions. Ok, in my example, a monodimensional element would be more suitable, but this was simply to test NextFEM regarding uniform temperature gradients in shells.
So, continuing with my test, I corrected the model freeing displacements in the z-direction, and, after the analysis, the model behaves as expected, except for stresses in x-direction. NextFEM gives sxx = 11805 kN/m2, but I expected sxx = 7869 kN/m2. I would expect a closer result.
Once more, many thanks for your fast response.
Dear NextFEM admin and parhyang: Thank you both. Definitely, to estimate negative moments with some confidence in slabs at continuity supports we have to use finite elements with very small size near the supports (size in the order of magnitude of the slab thickness).
Many Thanks for your very fast response. Thanks also for the free, basic version of the program. What I like best is its very simple interface with Python, making it possible to construct a model in few minutes (using templates). For me, the GUI is good to view results, not so much to build the model.
So, we may conclude that, although the implemented finite element has the advantage of avoiding stress concentrations and peaks (which is the case in many situations, for example concentrated loads on shells), if there is some real peak, we must use a refined mesh, with very small size.
Thank you very much for the update. I’ve just tested the method addThermalDistLoad() in several beams (doble-fixed, fixed-supported and continuous) and everything worked as expected, both uniform gradient and linear gradient. Congratulations!
In the case of uniform gradient the result given by NextFEM (compression) is obviously correct. The doubt is only about linear gradient.
Congratulations for the 2.2.0.5 release. I made some tests, and everything seems work perfectly. I also notice that it was made an improvement in API for Python. Now we can specify several load values and the corresponding positions:
nf.addBeamLoad(
elem = e1,
values = [0, -12, -12, 0],
positions = [0.0, 1.0, 4.0, 5.0],
direction = 2,
loadcase = ‘lc4’,
local = True,
)Is there a change log so that we can look for the improvements in each release?
Thanks for this very nice program.Sorry, but the problem with non-uniform loads on beams persists. For a simple supported beam with a span of 5 m and a triangular load, 0 at the beginning and 12 kN/m at the end, the moment at the mid-span is 18.75 kNm, but the program gives a strange result (a negative value!). Please verify this. Thanks.
