rclab-auth / gidopensees

GiD+OpenSees Interface
http://gidopensees.rclab.civil.auth.gr
GNU General Public License v3.0
94 stars 42 forks source link

Geometrical Transformation #46

Closed tejeswar91 closed 6 years ago

tejeswar91 commented 6 years ago

Respected Dr V. Papanikolaou,

I have got this doubt while looking at the way how GiD+OpenSees performs writing the geometrical transformation.

untitled Figure 1

capture 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

vpapanik commented 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

vpapanik commented 6 years ago

You can also see the local axes from either the end of the .tcl file or through the graphical postprocessor

tejeswar91 commented 6 years ago

image Figure 1

image 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.

vpapanik commented 6 years ago

Could you please replicate the models from fig. 1 and 2 in GiD+OpenSees, save them and attach them here ;

vpapanik commented 6 years ago

for the second one, use global Y as the vertical axis (General data -> modeling options window).

vpapanik commented 6 years ago

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.

tejeswar91 commented 6 years ago

image Illustration 1

image 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

vpapanik commented 6 years ago

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).

tejeswar91 commented 6 years ago

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. image

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. image

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

tejeswar91 commented 6 years ago

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

image 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.

vpapanik commented 6 years ago

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.

image

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.

vpapanik commented 6 years ago

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.

tejeswar91 commented 6 years ago

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

vpapanik commented 6 years ago

Thanks a lot, files sent. Please report back here. Thanks again for your assistance.

tejeswar91 commented 6 years ago

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)

MultipleAngles-3D-VertY.txt

Geometric Transformation

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.

ElasticBeamElements.txt

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,

snapshot

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.

image

Kindly let me know if the explanation seems to wrong.

Attached here the model

MultipleAngles-3D-VertY.gid

MultipleAngles-3D-VertY.gid.zip

Thanks and regards, Tejeswar

vpapanik commented 6 years ago

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).

image

Please tell me if the above is clear for you or if I am missing something.

vpapanik commented 6 years ago

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.

image

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.

tejeswar91 commented 6 years ago

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

vpapanik commented 6 years ago

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.

prafulla-malla commented 5 years ago

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)]; }