VERSION 6.5000

"mhanifiata":8e07451y" said:
in some projects, especially the 1st floor wall area is taken as zero by the program. Therefore, it gives the message of increase system rigidity. I was wondering if anyone else has encountered this problem
"mhanifiata" :8e07451y" said:
file is attached. I solved my problem by manually defining the wall area in the floor parameters... I think this happened after the transition to the 6.2007 version
Hello, In your program project, TDY applies the provision in the starting sentence of Article 2.3.2.3: "In buildings with B1 type irregularity, If the sum of the infill wall areas is more than the one on the upper floor, the infill walls will not be taken into account in the calculation of the n. Therefore, x-direction 1st and 3rd floor Ak values are taken as zero and zero is printed on 6.2007. Note: In the new version, we do not print "zero" the Ak values that enter this condition, we print the calculated values, but we do not take them into account. You can check the latest status in the beta version (6.405) I sent you... Good work...
 
hello sir. I'm reviewing your post. In this new version, there was no study on cork flooring systems. Is there such a work program in the coming days? There are a few things I want to summarize - when cork floors are used in mixed systems, the punching calculation is done only with the definition of column heading. can this be facilitated... eg beams on the outside, elevators, stairwells etc. inside. such as buildings with slabs... -We define beams (actually, not beams) at the floor thickness for earthquake calculation in unbeamed floors. which means creating two separate systems. It needs to be combined. We expect convenience. - Automatic creation of support bands or a new element definition for the support band should be introduced. thank you...
 
greetings... there are some ready-made tools to increase the stapling strength in non-beamed floors. Does anyone have an opinion on them?
 
Hello.. It would be good if the possibility of defining beams is introduced between the U-type polygon columns (for elevator buckets).
 
Hello Mr. Zeki,
"zeki78":2dp365v9" said:
Hello.. It would be good if the possibility of defining beams between U-type polygon columns (for elevator buckets) is introduced.
This facility is available in the program. Entering it as a panel and modeling it as a shell is sufficient for definition. Polygon columns entered as columns have a single node in the beam plane. When we want to connect a beam to this element, we will want to connect a two-node beam element to a single-node element. This data entry is suitable for the nature of the work. In short, it would be a healthier approach to define U-type polygon columns with 3-armed shell curtain elements and model them as shells.In addition, the column application drawings of polygon columns modeled as shells are also made completely in the program (in the column application, either open it on site or detail it outside) Good work...
 
Hello Hakan, I am making the elevator bucket elements using curtain elements as you say, but in this case, there are 2 situations that I do not like. 1) Since the edges of the elevator bucket are not very large, the dimensions of the curtain we use do not comply with the 1/7 rule. 2) There is no control such as column beam connection shear safety control on the curtains. For these reasons, I would like to define the elevator bucket as a polygon column. Good luck with.
 
Mr. Zeki78 , This cannot be possible in any international program. Because this is against the finite element logic. You cannot enter a polygon column and define a beam at floor level. Programs such as Sap2000 etaps also allow data entry like ide. Best regards
 
"zeki78":2kgoim34" said:
1) Since the edges of the elevator bucket are not very large, the dimensions of the curtain we use do not comply with the 1/7 rule.
We can think of the elevator bucket as a long element curled into an empty mass in the middle. I think 1 It is important to be able to work together with the system as a whole by dividing it into finite elements rather than complying with /7...
"zeki78":2kgoim34" said:
There is no such control as column beam connection shear safety control on curtains.
For the same reason, these elements I think it should be exempted from this control. However, if you still do not want to exempt it, you can model the element as a bar/shell mixed by defining the element as column-wall-column according to the arm lengths. For example, you define one of the arms as a column and the other elements as a finite element panel object. Finite elements will also divide the column exactly and the system behavior will thus be idealized in the most accurate way. Column-beam junction control is performed for the element that you define as a column. I think that at least one arm of a polygon column with a beam connected in the middle must provide a ratio of 1/7. You can enter the arms that provide the 1/7 ratio as a panel, and the arms that do not provide a column as a column. Good work...
 
Re: VERSION 6.5000 - curtain dimensions The picture below shows the plan of a curtain. The size of the curtain in the plan is 20/140 cm, as can be seen from the measurement. However, the length of the curtain used in the naming of the curtain is written as 165 cm. As can be seen in the second picture, it is seen that it is taken into account as 165 cm in calculations. In addition, 1/7 warning is given in geometry control for the same curtain. For example, in a project, 3 curtains of the same size (20/140 cm) have 3 different naming and calculations as 165 cm for one, 200 cm for one and 140 cm for the other. In fact, it is seen that there is a confusion in the size writings on the frets. (Besides, there is no mistake in the data entry, the controls seem normal.) Since this difference changes the Hw/Lw calculations and the fret end region conditions, while the end region is created in some curtains with the same characteristics, in others. is not created. What could be the reason for this?
 
Hello, In the drawing you added, the length of the BP17 curtain is considered as if there is no column until the point where it intersects with the other curtains due to the curtain combinations. We will review the situation and convey it to the R&D team. Good work
 
"dabanlio":1gpzfqda" said:
What could be the reason for this?
Hello, BP17 panel joins with the BP14 panel and the other panel coming from above, so the length of the BP17 panel is taken to the end point of the other panels. In short, the program is different panel-column According to their combination, it can make some adjustments. After reading your message, I made some experiments. I am attaching the screenshot. We can see that an acceptable harmony is applied between the calculation and the drawing, while the panel sizes are accepted by the program. However, if you add your project to the message, we can take a closer look at the situation you mentioned. If it is too big to add, you can send it to [email protected]) Take it easy, good work
 
Hello
In the drawing you added, the length of the BP17 curtain is considered as if there is no column, up to the point where it intersects with the other curtains, due to the curtain combinations.
This explanation by Levent and detailed information by Hakan explains the situation. In the previous message, I mentioned different curtain lengths. Here, I understand from the explanation made that those lengths vary with the size of the combined curtains. So actually there is no inconsistency[/b] in the program in terms of giving different dimensions[/b], I want to express this to avoid misunderstandings. In this case, in wall/curtain and column/curtain combinations, there are junction regions that remain in the common domain[/b] of the joining elements . thanks.
 
Greetings... I have already reported the attached drawing problem. that is, deep beam-shallow beam intersections, deep beam hollow beam intersections...
 
curved beam drawings are created without errors. The new slope definition is very accurate. When I took only the beam support detail, I saw that the drawing there did not fit with the slope. It's not a drawing I use a lot. I still wanted to point out. new mold plan drawing-section drawing is also nice... pdf transfer job is very good... congratulations... ide has established a very high level communication with its customers thanks to this forum. A very strong communication network was formed on reinforced concrete structures. I also think that ide should invite its customers to its own office and integrate them with the team... or organize chat meetings on the basis of provinces... an atmosphere of spiritual unity should be created... we are alone; There are a few issues that are treated like stepchildren (like). 1-existing structural analysis and reinforcement detail support 2-steel structure analysis/drawing 3-beamless tiled systems 4-tunnel formwork type buildings... meanwhile, I purchased software for the calculation-drawing of simple steel structures. I would like to know if ideyapı is conducting a study on steel. because I started work to get a software related to general structure analysis. I'm reviewing. I would very much like this software to be ide. Best regards...
 
Inclined tiling definition causes an error on the curtains (panels)... Since the definition of panels at two different levels cannot be made, panels in the direction parallel to the slope cannot be adjusted...
 
In the case you mention, although there is no possibility to make the tops of the panels sloped, there is no problem with support in the slab analysis. You can open the deformations and check the support status from the deformation of the slab.
 
Dear İde building officials and friends who participated in the forum: If you examine the attached project, you will see that the beam drawings are not constantly drawn on the sheet.
 
Back
Top