This is a test recommended by the National Agency for Finite Element Methods and Standards (U.K.): Test LE3 from NAFEMS publication TNSB, Rev. 3, “The Standard NAFEMS Benchmarks,” October 1990.
Target solution: ux= 185 mm at point A.
Solving this test I have found two main issues/limitations and what I think it’s a bug.
-Unused defined sets are erased from final inp if not used. This makes writing custom cards for given sets more complicated. I would kindly suggest to keep them unless I’m unaware of some drawback.
-User custom cards are erased after certain operations. That was reported here: Deactivation of Step erase user custom cards. Issue remains and can make someone loose nerves if trying to set up a model with custom keywords. One never knows if new cards have failed or part of the previous cards have been erased.
After sorting those points and minimum mesh refinement agreement is excellent .
Model seems to confirm that the rotational DOFS after a cylindrical transformation are still usable and work as expected on shells. I know because this test only works if the transformation card is active for the Rot DOFS.
I can’t share pmx files sorry so let’s see how I could explain it. I have attached the inp.
I have repeat the set up trying to follow my previous sequence, including the mistaken attempts.
1-Apply a displacement BC in a rectangular coordinate system in which Rotational DOFS are involved.
Run the model.
Switch to a Cylindrical coordinate system (in which no Rotational DOFs are available)
The previous rotational DOfs are not erased.
*Boundary
N_EA, 3, 3, 0
N_EA, 4, 4, 0 <---------------Remains from previous Rectangular coordinate system
N_EA, 5, 5, 0 <---------------Remains from previous Rectangular coordinate system
2-I have identified another bug in the process. I didn’t saw it because I wrote custom cards for the loads too. Now loads are introduced in the GUI.
Load for node C. I have request the load to be applied in the Global coordinate system. As I have previously applied a transformation to the shell in which node C is contained, load is applied in the wrong direction.
I think I also warn about this point in a previous post. Prepomax should check if the node where the loads is acting has a transform to apply the adrees the load before wrinting into the inp so direction match with the one requested by the user.
4-Regarding how to avoid erasing custom cards I don’t know.
Would it be possible to create the custom card as any other card into the proper position in the tree?. It would open a text box for the user to write whatever he wants. It could also be activated / deactivated.
I think we discussed this problem in one of the posts already. Since it is not always easy to determine what the user wants to do, my decision at the end of the discussion was to add only a model check before the analysis is submitted that will warn the user that he is mixing up the coordinate systems. Then he will have to fix the model.
This happens in some situations. I debugged this problem in one of the previous versions, so I thought the problem was solved. For debugging, I would really need your .pmx model since situations where it happens are complex. If you cannot share the model, recreating the problem with a simpler model would suffice. The other thing I could do is add an option to display the hidden internal sets in the model tree. This option should then be only with great caution.
Yes, that is also something I have in my head. It would require a lot of code changes and it would allow the user to add keywords only to the existing three items but would greatly help with positioning of the keywords in the .inp file.
According to the documentation, the rotational degrees of freedom should not be defined on the nodes where the transformation card is used. Is there any proof that it works for all coordinate system configurations?
as i remembering on nonliear shell buckling analysis of cylinder shown a rotational restraint at local coordinate system generated automatically when transform being used. It become hinged i.e rotation free if not defined.
*edited
i checked again and i can be wrong or missing, rotational restraint need to be added.
