… which are still not merged even after a year or so…
Some were reviewed and closed (after solving the related issues) by Guido shortly before the release of 2.21 but there are still quite a few left. But it’s the number of issues that’s really worrying here. Hopefully, he will find some time to resolve at least a few of them. Especially those that are nasty bugs, not just known limitations.
1 Like
Very good observation. I don’t even think of it, such kind of observation. Thanks a lot for sharing and also for everyone for keep sharing a very helpful information and observation.
I am aware that although some of the bug reports have not been cleaned up and reclassified as solved, they have been worked on. Specifically I reported a problem with the Courant number in explicit and saw some changes in the code about it.
It is possible that this is just a cosmetic issue or a re-classification of the report as resolved. Something like what Matej does from time to time that reviews all the posts and closes the ones that are solved.
What do you think would be the kindest way to ask Don Guido about the current status of the bug list?
I don’t want to be a nuisance or overlap with other users.
I usually just e-mail him asking to take a look at some issues of particular importance (especially when there are several such urgent issues waiting to be resolved). It seems that he doesn’t mind those remainders and always provides a comprehensive answer. I may contact him again soon as I wanted to talk with him about the issues with rigid body constraints and initial velocity in explicit dynamics with 2D/shell elements, among the others. I would also mention other bugs like the one discussed here.
i do simple recreate the model, and it seems all the solver (Spooles, PaStiX, Pardiso) given consistent and identical results.
p.s unit load is -1000N and quadratic hexahedral element (C3D20R) being used.
i heard about the problem of Spooles MT in frequency and buckling analysis, in this case a distribution from CFTurbo FEA probably can solve the problems.
Yes, it can give good results like when the load is 1 N or 470437.10 N (the OP’s case). The problems start when the load is larger than the buckling load and the issues might be mesh-dependent as well.
if i can remember correctly, this problem has been fixed by Victor from Mecway (many thanks). Simple re-testing with load of -500000N for the problem cases above, still provide consistent result for all solver here.
I reported the issue here: First buckling mode skipped when applied load is much bigger than buckling load · Issue #74 · Dhondtguido/CalculiX · GitHub
Apparently because it’s still close to buckling load. 980665 N causes problems.
i can confirm. It seems load magnitudes still can be greater than buckling loads until two times, out of these ranges the lowest factor did not report well and it jumps to next probable buckling shapes.
I’m studying a reinforcements for a column against buckling. For this aim I started a buckling analysis of a simple HEB200 column using RBE on the base and on the head of the column. I found a strange behaviour of the default CCX solver on Prepomax: With a compression load of 1 kN the results are compatible with Euler theory and the first buckling mode is relative to instability around the weak axis, which is obvious. Augmenting the compression load to 1000 kN the first buckling mode disappear, maybe because is less than 1. I think that’s could be dangerous because buckling factors less than 1 are neglected. Are there some parameters that I neglected?
1 isn’t a hard limit, and it can produce results a little lower than that.
1 Like
It’s highly mesh- and solver-dependent too but the problem is still there in most cases.