ПЗ (1191596), страница 3

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 3)

Порядок расчёта выполняется в следующем порядке:

– проверка условия прочности по касательным напряжениям;

– проверка условия прочности по нормальным напряжениям;

– проверка на выносливость;

– расчет на жесткость.

2.1 Проверка условия прочности по касательным напряжениям

Для принятого в типовом проекте прокатного двутавра(рисунок 6) принимаем его следующие геометрические характеристики:

S – статический момент сдвигаемой части сечения брутто относительно нейтральной оси;

J – момент инерции сечения брутто относительно оси Х;

δ – толщина стенки балки.

В соответствии с типовым проектом пролетного строения принимаем:

N – число балок в пролетном строении, шт;

– полный пролет, м;

– расчетный пролет;

Q_пс – массу пролетного строения с мостовым полотном, т.

Для указанной в задании марки стали принимается её расчетное сопротивление на срез.

Рисунок 4 - Двутавр

По исходным данным определяют:

– постоянную равномерно-распределенную нагрузку от собственной массы пролетного строения в т/м:

(1)

– коэффициент надежности по нагрузке к временным нагрузкам:

(2)

– площадь линии влияния поперечных сил однопролетной статически-определимой балки в м:

(3)

– динамический коэффициент:

(4)

– расчетная поперечная сила на опоре в кг:

(5)

где 10³ – переводной коэффициент из т в кг.

– максимальное касательное напряжение в сечении стенки, вычисленное в предположении упругой работы (в кг/см²):

(6)

– минимальное касательное напряжение в сечении стенки, вычисленное в предположении упругой работы (в кг/см²):

(7)

– коэффициент, учитывающий ограниченное развитие пластических деформаций в сечении при сдвиге:

(8)

– максимальное касательное напряжение в сечении стенки, вычисленное в предположении упругой работы (в кг/см²) и сравниваем его с расчетным сопротивлением стали на срез (в кг/см²) умноженному на коэффициент условий работы и коэффициент, учитывающий ограниченное развитие пластических деформаций в сечении при сдвиге:

(9)

Если условие (9) выполняется, то условие прочности по касательным напряжениям удовлетворяется и расчет можно продолжать, если нет, то необходимо принять двутавр с более высокими геометрическими характеристиками поперечного сечения или увеличить количество балок в пролетном строении и выполнить расчет повторно.

Рисунок 5 – Пример расположения опорных балок

2.2 Проверка условия прочности по нормальным напряжениям

Кроме вышеуказанных исходных данных и результатов расчетов необходимо:

– для принятого в типовом проекте прокатного двутавра выбираем W_n – момент сопротивления сечения нетто относительно оси Х, см³.

– марка стали принимается её расчетное сопротивление по пределу текучести .

– в соответствии с заданной шириной колеи принимается нормативная временная вертикальная нагрузка от подвижного состава К (т/м) при .

По указанным выше исходным данным определяем:

– площадь линии влияния изгибающих моментов однопролетной статически-определимой балки в м²:

(10)

– расчетный изгибающий момент в середине пролета в :

(11)

где 10⁵ – переводной коэффициент из в .

– коэффициент, учитывающий ограниченное развитие пластических деформаций в сечении:

Если (12)

Если (13)

– определяем максимальное нормальное напряжение при изгибе и сравниваем его с расчетным сопротивлением стали при изгибе:

(14)

Если условие (14) выполняется, то условие прочности по нормальным напряжениям удовлетворяется и расчет можно продолжать, если нет, то необходимо принять двутавр с более высокими геометрическими характеристиками поперечного сечения или увеличить количество балок в пролетном строении и выполнить расчет повторно.

2.3 Проверка на выносливость

Кроме вышеуказанных исходных данных и результатов расчетов необходимо:

– принять нормативную временную вертикальную нагрузку от подвижного состава К (т/м) при из проверки условия прочности по нормальным напряжениям.

По указанным выше исходным данным определяем:

– максимальный расчетный изгибающий момент в :

(15)

– минимальный расчетный изгибающий момент в :

(16)

– характеристику цикла переменных напряжений:

(17)

– коэффициент понижения расчетного сопротивления основного металла:

(18)

– проверка условия прочности при расчете на выносливость:

(19)

Если условие (22) выполняется, то условие прочности при расчете на выносливость удовлетворяется и расчет можно продолжать, если нет, то необходимо принять двутавр с более высокими геометрическими характеристиками поперечного сечения или увеличить количество балок в пролетном строении и выполнить расчет повторно.

Рисунок 6 – Пример опоры с применением двутавра

2.4 Расчет на жесткость

Кроме вышеуказанных исходных данных и результатов расчетов необходимо:

– принять нормативную временную вертикальную нагрузку от подвижного состава К (т/м) при из проверки условия прочности по нормальным напряжениям.

По указанным исходным данным определяем:

– вертикальный расчетный прогиб от нормативной временной вертикальной нагрузки, см:

(20)

где 10⁹ – переводной коэффициент.

– вертикальный допускаемый прогиб от нормативной временной вертикальной нагрузки, см:

(21)

– проверка условия жесткости:

(22)

Если условие (22) выполняется, то условие жесткости удовлетворяется и расчет закончен, если нет, то необходимо принять двутавр с более высокими геометрическими характеристиками поперечного сечения или увеличить количество балок в пролетном строении и выполнить расчет повторно.

Для расчета свайных, стоечных и других опор, не имеющих соединительных элементов (диафрагм) между стойками, могут использоваться программы для расчета высоких свайных ростверков, как правило, допускающие различные варианты заделки свай в грунте (упругая или жесткая заделка). При расчете стоечных опор по таким программам принимается жесткая заделка стоек в фундаментах.

3 РЕАЛИЗАЦИЯ ПРОГРАММНОГО ПРОДУКТА

При разработке приложения были использованы система Git и среда разработки Qt Creator.

3.1 Git

Рисунок 7 – Данные для каждого файла в стандартных СКВ

Г
лавное отличие Git'а от любых других СКВ – это то, как Git отображает свои данные. Большинство других систем хранит информацию как список изменений для файлов. Эти системы относятся к хранимым данным как к набору файлов и изменений, сделанных для каждого из этих файлов во времени, как показано на рисунке 9.

Git не хранит свои данные в таком виде. Вместо этого Git считает хранимые данные набором слепков небольшой файловой системы. Каждый раз, когда пользователь фиксирует текущую версию проекта, Git, сохраняет слепок того, как выглядят все файлы проекта на текущий момент. Ради эффективности, если файл не менялся, Git не сохраняет файл снова, а делает ссылку на ранее сохранённый файл. То, как Git подходит к хранению данных, представлено на рисунке 10.

Рисунок 8 – Хранение данных в системе Git.

Э
то важное отличие Git'а от практически всех других систем контроля версий. Из–за него Git вынужден пересмотреть практически все аспекты контроля версий, которые другие системы переняли от своих предшественниц. Git больше похож на небольшую файловую систему с инструментами, работающими поверх неё, чем на просто СКВ.

Для совершения большинства операций в Git'е необходимы только локальные файлы и ресурсы, в большинстве случаев, информация с других компьютеров в сети не нужна. При использовании централизованных систем, на большинство операций накладывается сетевая задержка. Однако модуль Git в этом плане удобен, поскольку вся история проекта хранится локально у пользователя на диске, большинство операций кажутся практически мгновенными.

К примеру, чтобы показать историю проекта, Git'у не нужно скачивать её с сервера, он просто читает её прямо из локального репозитория. Поэтому историю пользователь видит практически мгновенно. При необходимости просмотреть изменения между текущей версией файла и версией, сделанной месяц назад, Git может взять файл месячной давности и вычислить разницу на месте, вместо того чтобы запрашивать разницу у СКВ-сервера или качать с него старую версию файла и делать локальное сравнение.

Кроме того, работа локально означает, что мало чего нельзя сделать без доступа к Сети или VPN. При работе в транспорте или в любом месте без сети достаточно делать коммиты, а затем отправить их, как только станет доступна сеть. Если VPN-клиент не отвечает, всё равно можно продолжать работать. Во многих других системах это невозможно или же крайне неудобно. Например, используя Perforce, мало что можно сделать без соединения с сервером. Работая с Subversion и CVS, можно редактировать файлы, но сохранить изменения в базу данных нельзя (потому что она отключена от репозитория). Вроде ничего серьёзного, но для работы программиста это составляет определённые трудности.

Перед сохранением любого файла Git вычисляет контрольную сумму, и она становится индексом этого файла. Поэтому невозможно изменить содержимое файла или каталога так, чтобы Git не узнал об этом. Эта функциональность встроена в сам фундамент Git'а и является важной составляющей его философии. Если информация потеряется при передаче или повредится на диске, Git всегда это выявит.

Механизм, используемый Git'ом для вычисления контрольных сумм, называется SHA-1 хешем. Это строка из 40 шестнадцатеричных символов (0-9 и a-f), вычисляемая в Git'е на основе содержимого файла или структуры каталога. SHA-1 хеш выглядит примерно так:

24b9da6552252987aa493b52f8696cd6d3b00373

Работая с Git'ом, пользователь встречает эти хеши повсюду, поскольку модуль их очень широко использует. Фактически, в своей базе данных Git сохраняет всё не по именам файлов, а по хешам их содержимого.

Практически все действия, которые совершаются в Git'е, только добавляют данные в базу. Очень сложно заставить систему удалить данные или сделать что-то неотменяемое. Можно, как и в любой другой СКВ, потерять данные, которые ещё не были сохранены, но как только они зафиксированы, их очень сложно потерять, особенно если регулярно отправлять изменения в другой репозиторий.

В Git'е файлы могут находиться в одном из трёх состояний: зафиксированном, изменённом и подготовленном. "Зафиксированный" означает, что файл уже сохранён в локальной базе пользователя. К изменённым относятся файлы, которые поменялись, но ещё не были зафиксированы. Подготовленные файлы – это изменённые файлы, отмеченные для включения в следующий коммит.

Рисунок 9 – Локальный обмен данными Git’а

Таким образом, в проектах, использующих Git, есть три части: каталог Git'а (Git directory), рабочий каталог (working directory) и область подготовленных файлов (staging area).

Характеристики

Список файлов ВКР