Closed tejeswar91 closed 6 years ago
I couldn't understand what you are writing, please elaborate. The rules behind local axes are taken form here : http://opensees.berkeley.edu/wiki/index.php/Linear_Transformation
You can also see the local axes from either the end of the .tcl file or through the graphical postprocessor
Figure 1
Figure 2
The illustration in the given link is only for vertical and horizontal members. But for diagonal members, if I am not wrong, geometrical transformation changes accordingly as shown in the fig. 1 & 2. Where, x, y, z represents the local axis X, Y, Z represents the global axis
Kindly correct me if my understanding is wrong. Thanks in advance.
Could you please replicate the models from fig. 1 and 2 in GiD+OpenSees, save them and attach them here ;
for the second one, use global Y as the vertical axis (General data -> modeling options window).
also pay attention to the direction an element is drawn, i.e. which is the first point and which is second. The local axis - x always goes from start point to finish point along the element length.
Illustration 1
Illustration 2
geotag.gid.zip GiD attachment
In the illustration 1, element and geometrical transformation in table 1 is copied from Tcl file generated from the GiD model.
x, y, z represents the local axis X, Y, Z represents the global axis
Element 8, 10 and 11 in the Illustration 1 represent member 4, 5 and 3 respectively in Illustration 2. As per the GiD file generated all these non-vertical or non-horizontal members have their normals in global Y axis where is not justifiable.
Element 8 or member 4 is in global YZ plane then it is easy to consider vecxz out of YZ plane, i.e., in global X
Element 11 or member 3 is in global XY plane then it is easy to consider vecxz out of XY plane, i.e., in global Z
Element 10 or member 5 is in a plane making some angle with XY and YZ planes, then the geometrical transformation should be as shown in illustration 2
It is up to the user to define Vecxz. In GiD+OpenSees interface, it is always defined as the global vertical direction (Y or Z, whatever the user chooses). Then, the local y and z vectors are defined according to this Vecxz. There may be other definitions also, it's up to the user. What is the source of the definition you are using in illustration 2 ?
However, the correct local axis vectors are shown in the postprocessing window, not during preprocessing. You can check them there. I found out that there's a mistake in displaying vectors in the oblique diagonal member, so I have to re-check the code again (it hangs up with the previous OpenSeesPost.exe file).
I have produced the same illustration in OpenSees navigator and extracted the Tcl files. The files are attached here. geotag.zip
This is the snapshot of the model from opensees navigator.
Here the elements 9, 11 and 10 represent elements of gid model 8, 10 and 11 respectively.
Following is the information obtained from the extracted Tcl files.
It can be observed here that element 9 is in a plane parallel to YZ thus the normal is out of the YZ plane and vecxz is considered parallel to X-axis.
And element 10 is in XY plane but here normal is not considered as I suggested in the earlier explanations, but both represent the same orientation.
Element 11 is in a plane making some angle with XY and YZ planes so the components are taken
I have checked with the post-processing, the vectors representation seems reasonable but I have one doubt regarding the same.
For example, E – element tag N – Node tag S – section assigned to an element d – depth of section w – width of the section a – element normal axis b – parallel to global vertical
Figure 1
Looking at the fig. 1, exact normal of the element (E1) is 'a' where the section should pass but as per the interpretation of interface, section passes through 'b'. And the exported Tcl files are sent to OpenSees.exe for analysis. Where OpenSees consider the calculation according to the global vertical axis while transforming beam element stiffness and resisting force from the basic local system to the global system. And I feel this may lead to inaccurate results. This is to the best of my knowledge. Thanks in advance.
Dear tejeswar91, thanks a lot for your valuable contribution.
I have checked the issue extensively and found out that there was a calculation/display problem when the global Y axis is selected as the vertical axis in a 3D problem. However, selecting the Z axis is recommended for this case, that's why we didn't encountered the problem in the past. Now the calculation code (euler angles for local axis display in GiD) has been enhanced, and everything works fine.
Please note that in GiD+OpenSees we have agreed upon a convention for defining the local axes of elements for both 2D and 3D cases. This convention is described in the 'Hover for local axis info' button, I attach it again here.
We believe that it is a fair convention for defining the local axes in all cases. If you have a different suggestion that is easier to implement, please do.
We would be grateful if you could check the corrected version (v2.5.2) which I can send you by email before release. Please provide me your email in order to do so. Thanks again.
I can also send you a bunch of testing models (together with the ones that you have already sent to me), transformed to the new version, in order to check for yourself that everything is in order.
Thank you for your kind response. Please check your institutional mail "billy@civil.auth.gr". I have sent my contact mail at the same address.
Thanks and regards, Tejeswar
Thanks a lot, files sent. Please report back here. Thanks again for your assistance.
Hello Dr. V. Papanikolaou,
I have gone through the new version of GiD+OpenSees. I have observed that the graphical representation of normals is obvious. But when I have extracted the Tcl files of "MultipleAngles-3D-VertY" (I have attached here as .txt file since this webplatform doesnot supports .tcl files), the geometric tranformation is showing as follows (refer to line 85 in the attached .txt file)
geomTransf Linear 1 -1 0 0 geomTransf PDelta 3 -1 0 0 geomTransf Corotational 5 -1 0 0 geomTransf Linear 2 0 1 0 geomTransf PDelta 4 0 1 0 geomTransf Corotational 6 0 1 0
I have used elastic beam column elements for instance. Further I have checked with the element files in attached below as .txt (original format ".bas"), please check with the lines from 36 to 60 as well as 130 to 172 which needs to be revisited.
I feel GiD has nothing to do with the analysis but OpenSees follows line direction as local x-axis and corresponding normals. For example in the following figure element 13 is an oblique element,
As per the extracted .tcl file, element 13 has normal (i.e, Vxz) is in global Y direction which is not appropriate as the GiD's graphical representation seems to be.
Kindly let me know if the explanation seems to wrong.
Attached here the model
MultipleAngles-3D-VertY.gid.zip
Thanks and regards, Tejeswar
Dear Tejeswar,
Thanks again for your feedback.
I think that you may have misunderstood the meaning of Vxz, that has nothing to do with the final local axis vectors Vy and Vz (in the general case). If the global Y axis is defined as the vertical axis, then the orientation vector Vxz coincides with global Y. That means that the local-x axis (always defined by the element orientation) and global Y (= Vxz) form a plane where the local-z axis lies within (always normal to local-x). Then the local-y axis is vertical to the other two that are already defined (right-hand rule)
If you check at the end of the .tcl file, the orientation vectors for all three local axes is shown, together with their literal representation (+X,+Y,+Z,-X,-Y,-Z if they coincide with the respective global axes, or 'O' if the respective local axis is oblique). For instance, on element #13, all three local axes are oblique (O,O,O).
Please tell me if the above is clear for you or if I am missing something.
Please note that the correct local axes will be shown in GiD in the POSTPROCESSING phase, with this tool. You cannot show the correct local axes in the preprocessing phase, since they are not yet calculated. Only the local-x orientation is useful in the preprocessing phase, if you just want to reverse it.
A1 is local-x, A2 is local-y and A3 is local-z
note that all elements have a local-x-z plane formed with their local-x and global Y.
This rule excludes 'vertical' elements, when their local-x already coincides with the selected vertical axis Y. For these elements only, the Vxz vector is taken as the minus global X.
However, selecting the global Y axis as a vertical axis for 3D models is not recommended. The default is the Z axis as the vertical one. For instance, on a building we usually draw the floors in the XY plane and its height goes along Z.
Thanks, a lot Dr V. Papanikolaou, now it is obvious to me. I am interpreting that Vecxz represents one of the normal axes and the other normal is calculated from the cross product of the 'x' and 'Vecxz'. I misunderstood from the explanation that was given in the OpenSees documentation. Although my wrong interpretation will not affect the results, your explanation is more simple to follow.
I am really thank you very much for your kind patience. Your interface is greatly helpful for visualization of OpenSees results. I am very glad to work with you and Gid+OpenSees interface in future as well.
Best regards, Tejeswar
Yes, Vecxz is just the vector that form the XZ plane with the local-x. Then, the other two local axes are calculated with vector products. Sometimes Vecxz coincides with a local axis, sometimes not (oblique elements).
Thanks a very lot for your contribution !
I will release an updated version within a few days.
This provided me a lot of information. is there any general formula . So, that i can rotate the cross-section. I was trying to do the analysis of column by rotating the section but I got stuck in transformation. Section is in XY plane and height in Z-direction
set nosRo 5; # total number of rotation done for section set transfTag 1 set pi 3.1444 for { set i 0 } { $i < $nosRo } { incr i } { set Theta [expr 360./$nosRo$i] geomTransf Corotational $transfTag [expr cos($pi/180.$Theta)] [expr cos($pi/2-$pi/180.$Theta)] [expr cos($pi/180.$Theta)]; }
Respected Dr V. Papanikolaou,
I have got this doubt while looking at the way how GiD+OpenSees performs writing the geometrical transformation.
Figure 1
Figure 2
I have created a small demonstration (fig. 2) based on the information given in fig.1. Based on the demonstrations, if I am not wrong I feel the results may not be in favour when the members are neither vertical nor horizontal since the geometrical transformation should be out of the plane instead the interface considers it in a global vertical axis. For example
For vertical Y-axis Slant member along X-axis: transformation should be in global Z-axis (out fo plane, XY) Slant member along Z-axis: transformation should be in global X-axis (out fo plane, ZY) Slant member with some angle in X & Z: transformation should be like "tx 0 tz"
Thanks in advance. Kindly forgive me if my understanding is wrong.
Best regards, Tejeswar