Однако насчет ограничения токов короткого замыкания (КЗ) — к сожалению, сверхпроводящий трансформатор — не самое лучшее решение.
Дело в том, что трансформатор обладает довольно большим ИНДУКТИВНЫМ X=jwL сопротивлением (при наличии сердечника). При расчетах токов короткого замыкания, во всяком случае для силовых трансформаторов, именно оно является определяющим.
Рассчитаем ток короткого замыкания за трансформатором, на стороне 10 кВ:
чисто индуктивный: Ik=Uном/sqrt(3)/X=11/1.73/0.794=8008 А
с учетом активного сопротивления: Ik=Uном/sqrt(3)/X=115/1.73/86,79=7998 А
Собственно, непонятно, почему для ограничения величины токов КЗ нужно использовать такой неудобный способ, как сверхпроводник и жидкий азот вместо изменения геометрических размеров магнитопровода и обмотки (как это обычно делается)?
Для сколь-нибудь значимого ограничения ТКЗ надо, чтобы активное сопротивление проводов в несверхпроводящем состоянии было бы сопоставимо с индуктивным, т.е. раз в 20 больше, чем сейчас есть...
Если уж токи КЗ очень большие, последовательно с трансформатором обычно подключают токоограничивающий реактор (http://slavenergo.ru/reaktory), чтобы сэкономить на оборудовании.
Добавим сюда, что переменное сопротивление трансформатора создаст проблемы при расчете уставок защит самого трансформатора и сети за ним, т.к. ток КЗ при этом посчитать толком будет невозможно. Да и несинусоидальный ток при КЗ также может вступить в конфликт с некоторыми алгоритмами защит.
Добавим также сюда, что всякие кабели 10 кВ имеют активное сопротивление порядка 0.3...0.2 Ом/км, реактивное порядка 0.1 Ом/км. Т.е. активные потери в обмотках трансформатора на самом деле много меньше потерь в кабелях.
Также следует отметить, что потери от вихревых токов в сердечнике (13 кВт в нашем случае) никуда не денутся, т.к. сердечник не сверхпроводящий.
В случае со всякими ММОРПГ — по-моему, там главное перестать общаться с теми, кто в этих играх сидит по уши, и все заканчивается само собой. Уже почти 10 лет как не играл.
Просто удалил WoW с компа в 2009 году. На PvE x1 с тех пор не играл вообще и принципиально не тянет играть в такие «покачайки».
На всяких аренах и РП (даже не пробуйте это) играл еще месяцев 6 в 2010-м. Затем удалил WoW совсем. Потом свой мини-РП проект. Мне говорили, что «бывших ролевиков не бывает». Бывают, в 2016-2017 завязал и с этим, как и с онлайн-кооперативами.
Тогда почувствовал, что «самая фантастическая вещь в Mass Effect это то, что у капитана Шепарда в 30 лет 12 друзей» — это блин не смешно.
А в одиночки на прохождение я пытался бросать играть, но что-то смысла особо не вижу. Иногда просто делать нечего.
Относительно напряжения. Активный и реактивный — смотрится угол между током и напряжением. Если отдельно ток без напряжения, то это просто ток, и нагрев от него I^2*R, I — действующее значение.
Если стоит страх за провода, можно просто смотреть на амперметр и все, безо всякого косинуса.
Компенсировать реактив, наверное, стоит только у чего-то довольно мощного, если суммарный ток большой и выходит за какой-то предел…
Вот это уже лучше. Получается, что целенаправленно вводить людям с вакциной ковид неэтично, поэтому делается большая группа и «авось там кто-то заболеет сам», и для этого берется большая группа народу, чтобы гарантированно кто-то заболел сам.
А наличие антител (не биолог ни разу) — оно не является свидетелством иммунитета? Т.е. условно берем у больного кровь, берем ковид, добавляем ковид в кровь, ковиду каюк — работает, нет — не работает. (Вообще вроде читал, что иммунитет там как-то завязан на нервную систему, т.е. там не все так просто, но все же).
Смысл в том, что вряд ли силой убеждения люди синтезируют себе антитела к COVID-19.
Вряд ли вообще это плацебо на третьей фазе испытаний нужно для доказательства действенности самого лекарства, доказательством действенности являются антитела к вирусу или, во всяком случае, что-то подобное (в идеале — чтобы человек более никогда не заболел, но как раз таки для этого плацебо не нужно, из-за плацебо человек как раз заболеть может).
Именно в связи с этим вопрос возник. Почему-то склоняюсь к мысли, что это плацебо на третьем этапе нужно для выявления побочек Т.е. если ухудшение/улучшение состояния привитых и контрольной группы коррелируют, то это не побочка, а если привитым в значительной массе стало плохо, а непривитым нет, то это побочка 100%, и изучается сила этих побочек.
А чисто из любопытства: а технически зачем нужно при испытаниях вакцины (именно вакцины) давать кому-то плацебо?
Единственное, что мне пришло в голову: что таким образом мы имеем группу привитых людей и как бы контрольную группу гарантированно непривитых и непереболевших ничем, и что можно учитывать за счет этого динамику изменения физического состояния пациентов, ничем не привитых.
Т.е. допустим начались какие-то там ухудшения самочувствия у кого-то из привитых, и чтобы не списать по ошибке отрицательный эффект на лекарство, смотрится по статистике — вот есть контрольная группа, и у 1% ее ухудшилось самочувствие, и у привитых ухудшилось самочувствие тоже у 1%, и обе группы равные по размеру, тогда получается, что с лекарством все ок, это просто статистика.
Маневрирование — да, проблема. Есть определенные соображения:
— момент первого выстрела все равно неизвестен (и направление — откуда — тоже). Все время маневрировать — очень затратно по топливу. Поэтому первый выстрел должен пойти, куда надо.
— маневрирование все же будет не с ускорением 20 км/с^2, а каким-то меньшим, зависит от двигателя. Если какие-нибудь ионные двигатели, которые разгоняют корабль неделями — особо не поманеврируешь.
— с расстояния 1000 км скорость 20 км/с дает максимальное угловое смещение atan(20/1000)=1.15 градуса/сек. Т.е. пушку надо крутить условно на 1 градус в секунду, это не так много. На фоне этого 1 градуса маневры с ускорением в несколько g дадут еще меньшие требуемые углы поворота. Т.е. вопрос в создании системы автоматического прецезионного позиционирования, желательно «по телескопу», чтобы не выдавать себя всякими работающими радарами.
Насколько сейчас это технически возможно — затрудняюсь ответить, но в будущем — почему бы и нет? Какой-нибудь «левитационный» подвес пушки в магнитном поле…
50-100 тысяч километров — там да, конечная скорость света, при маневрировании могут быть проблемы…
Вроде есть рентгеновские лазеры. Да, трудности есть.
Но мощность лазера большую сделать хотя бы теоретически можно (сделаем скидку на технологии будущего), и это оружие достигает цели со скоростью света. Пулю или ракету до околосветовой скорости еще не пойми как разгонять, а тут хотя бы сразу скорость «из коробки».
А вот всякие орбитальные межпланетные полеты, длящиеся годами, и потребность в огромном количестве топлива, или задача сбить 100 мелких дешевых спутников, запустив 100 дорогущих противокосмических ракет размером с Союз или Фалькон — все это выглядит тупиком.
Почему все бои в космосе рассматриваются как поражение цели какой-то ракетой, или пулеметом или еще чем-то таким материальным, и еще с элементами догфайта а-ля самолеты I (II) мировой? Почему нельзя сделать какой-нибудь прецезионно наводящийся лазер, который бьет на тысячу километров?
Почему-то думается, что бои в космосе, если они вообще произойдут, будут выглядеть так: летят 2 космических аппарата за сотни и тысячи километров друг от друга, далее один из аппаратов режет другой лазером напополам. Или каким-то мощным направленным импульсом выводит из строя всю электронику. Никаких сложных маневров и расходов горы топлива.
Насколько я знаю, при КЗ генераторы тоже разгоняются (при КЗ нагрузка активная почти ноль, большая индуктивность генератора ограничивает ток).
Так вот, КЗ длительностью примерно 0.3 с на таком генераторе — он вылетает от защиты по частоте (есть такие сведения о реальных генераторах примерно 1-3 МВт мощностью). Там сильно большого разгона, по идее, и не надо, достаточно включения в противофазе…
Посмотрел ваши видео на ютубе далее (4-6 серии), да, там это заметно, мотоцикл ездит иногда не вперед.
И еще заметил — паровыпускной клапан прямо под ногой, может, стоит «паровыхлопную трубу» сделать подлиннее, как у обычного мотоцикла?
Да и «газовыхлопную» трубу можно сделать загнутую назад.
Да, эквивалентно передаче структуры с данными. Но структура с данными получается как бы «с документацией», в ней четко написано, где там что.
Да, ООП в какой-то степени это сахар для правки кода и как бы поблокового написания.
Удобно, когда толком не знаешь, как все будет работать целиком, но знаешь, как должны работать отдельные куски.
Тогда в ООП-стиле эти куски пишутся (при этом идет обращение к одной структуре с данными), далее додумывается код остальной части программы (в структуру с данными дописываются поля), при этом правка уже написанного минимальная.
mex-файлы — для симулинка, имеется в виду?
Я с симулинком раньше возился-возился, потом проклял его тормознутость, и стал моделировать почти все самописным кодом.
если я правильно понимаю вопрос, вы спрашиваете, чем лучше
solver.coeff1=k1;
solver.coeff2=k2;
чем запихать в массив coeff=[k1,k2...kn] и скормить функции этот coeff, и дальше его сверху вниз передавать f1(f2(f3(...?
1) имена коэффициентам присвоены. Это удобно, если они разные по физическому смыслу.
2) Внутри функций можно обратиться к коэффициентам по имени.
3) Если захочется добавить новые коэффициенты, то все функции, которые с ними (новыми коэффициентами) не работают, просто остаются, какими были. Дописать коэффициенты «в хвост» — представьте, что они у вас физически разные по смыслу и перемешаются в ходе «апдейтов с дописыванием к концу массива».
2) Ад через точку с запятой в самом начале будет по смыслу совершенно понятными, 1 раз написал и все.
Т.е. вы присваиваете нормальные имена всем переменным, пихаете их в базу данных, дальше внутри функции вытаскиваете по имени все переменные, какие надо. Если толком непонятно, как точно будет устроен код, вы называете по имени все переменные, какие вам кажутся нужными и пишете кусок. Потом еще приписываете кусок. Т.е. код пишется как бы по кускам…
Заголовок спойлера
'Вот кусок класса (делал на VBA в экселе)
'для расчета нелинейной электрической цепи
Public R_load, L_load, R2, L2 As Double 'Это сопротивление и индуктивность
Public Im, Iexp, omega, phi, Tp As Double 'это параметры источника тока
Public FLmax, k As Double 'это параметры, отвечающие за нелинейную характеристику
Public w1, w2 As Double 'это коэффициент трансформации (моделировался трансформатор)
Private this_curveCoeffs As CurveCoeffs 'это коэффициенты в относительных единицах, отвечающие за нелинейную характеристику
Если этих коэффициентов очень много, и они разнородные по физическому смыслу (я делал расчет нелинейной электрической цепи с эмуляцией насыщения магнитопровода), то совать их в один массив — смерти подобно.
будет как раз кошмар вида coeff=[ад на 10 строчек через запятую].
Нелинейные дифура внутри требуют вычисления подфункций, в них тоже передаются аргументы, так что перепаковывать вот этот массив coeff для скармливания нижестоящему коду будет очень болезненно.
Много ООП при написании всяких GUI-приложений.
А так, в не-ГУИ приложениях — например, решение нелинейных дифуравнений методом Рунге-Кутты.
Если уравнение приводимо в явном виде к такой форме
dy/dx=f(x,y),
то пишете базу данных EqSolver, куда пихаете все коэффициенты, входящие в функцию f(x,y).
Далее
EqSolver solver=new EqSolver()
solver.coeff1=…
solver.coeff2=…
… так делаете все коэффициенты
1) У вас будет метод f=solver.f(x,y), внутри он будет обращаться к coeff1, coeff2… и возвращать значение
2) У вас будет универсальный метод расчета 1й итерации который вычисляет значение функции f как f=this.f(x,y) вместо f=f(x,y,coeff1,coeff2,,,,)
3) У вас будет универсальный метод, который вызывает в цикле метод расчета одной итерации, в итоге получается массив y по заданному массиву х и начальному значению y_start
При этом во всех методах не нужно будет писать множество аргументов, только что-то типа y=solver.Solve(x, y_start), внутри он вызывает y_next=this.MakeStep(x,y_previous), а MakeStep внутри вызывает f=this.f(x,y).
Речь про то, что в картинке под спойлером в сообщении выше. Статический метод класса MyClass.DoItStatic(MyClass item, int k) принимает аргумент item класса MyClass и залезает в его приватные поля (в картинке тест этой гипотезы в Visual Studio, все работает, код запускается и присваивает значение этому полю).
Статический метод любого другого класса, принимающий этот же объект, в его приватные поля уже залезть не может.
Хорошая статья!
Однако насчет ограничения токов короткого замыкания (КЗ) — к сожалению, сверхпроводящий трансформатор — не самое лучшее решение.
Дело в том, что трансформатор обладает довольно большим ИНДУКТИВНЫМ X=jwL сопротивлением (при наличии сердечника). При расчетах токов короткого замыкания, во всяком случае для силовых трансформаторов, именно оно является определяющим.
Чтобы не быть голословным, возьмем вот такой трансформатор
http://bemz.by/electro/transformers/90-tdn16000.html
Его сквозное сопротивление
Z=uk%/100Uном^2/Sном=10.5/10011^2/16=0.794 Ом
При этом активное сопротивление (на основе данных http://www.etk-oniks.ru/Maslyanye-transformatory/TDN-10000-16000.html)
R=dPkUном^2/Sном^2=(8510^-3)*11^2/16^2=0.04 Ом
Индуктивное сопротивление
X=корень(Z^2-R^2)=корень(0.794^2-0.04^2)=0.793 Ом
Рассчитаем ток короткого замыкания за трансформатором, на стороне 10 кВ:
чисто индуктивный: Ik=Uном/sqrt(3)/X=11/1.73/0.794=8008 А
с учетом активного сопротивления: Ik=Uном/sqrt(3)/X=115/1.73/86,79=7998 А
Собственно, непонятно, почему для ограничения величины токов КЗ нужно использовать такой неудобный способ, как сверхпроводник и жидкий азот вместо изменения геометрических размеров магнитопровода и обмотки (как это обычно делается)?
Для сколь-нибудь значимого ограничения ТКЗ надо, чтобы активное сопротивление проводов в несверхпроводящем состоянии было бы сопоставимо с индуктивным, т.е. раз в 20 больше, чем сейчас есть...
Если уж токи КЗ очень большие, последовательно с трансформатором обычно подключают токоограничивающий реактор (http://slavenergo.ru/reaktory), чтобы сэкономить на оборудовании.
Добавим сюда, что переменное сопротивление трансформатора создаст проблемы при расчете уставок защит самого трансформатора и сети за ним, т.к. ток КЗ при этом посчитать толком будет невозможно. Да и несинусоидальный ток при КЗ также может вступить в конфликт с некоторыми алгоритмами защит.
Добавим также сюда, что всякие кабели 10 кВ имеют активное сопротивление порядка 0.3...0.2 Ом/км, реактивное порядка 0.1 Ом/км. Т.е. активные потери в обмотках трансформатора на самом деле много меньше потерь в кабелях.
Также следует отметить, что потери от вихревых токов в сердечнике (13 кВт в нашем случае) никуда не денутся, т.к. сердечник не сверхпроводящий.
Просто удалил WoW с компа в 2009 году. На PvE x1 с тех пор не играл вообще и принципиально не тянет играть в такие «покачайки».
На всяких аренах и РП (даже не пробуйте это) играл еще месяцев 6 в 2010-м. Затем удалил WoW совсем. Потом свой мини-РП проект. Мне говорили, что «бывших ролевиков не бывает». Бывают, в 2016-2017 завязал и с этим, как и с онлайн-кооперативами.
Тогда почувствовал, что «самая фантастическая вещь в Mass Effect это то, что у капитана Шепарда в 30 лет 12 друзей» — это блин не смешно.
А в одиночки на прохождение я пытался бросать играть, но что-то смысла особо не вижу. Иногда просто делать нечего.
Не, придираться не собираюсь. Просто интересно, какие мощности устройств в итоге, какой ток это все в сумме потребляет с компенсацией и без.
Если стоит страх за провода, можно просто смотреть на амперметр и все, безо всякого косинуса.
Компенсировать реактив, наверное, стоит только у чего-то довольно мощного, если суммарный ток большой и выходит за какой-то предел…
www.jstor.org/stable/pdf/282570.pdf
А наличие антител (не биолог ни разу) — оно не является свидетелством иммунитета? Т.е. условно берем у больного кровь, берем ковид, добавляем ковид в кровь, ковиду каюк — работает, нет — не работает. (Вообще вроде читал, что иммунитет там как-то завязан на нервную систему, т.е. там не все так просто, но все же).
Вряд ли вообще это плацебо на третьей фазе испытаний нужно для доказательства действенности самого лекарства, доказательством действенности являются антитела к вирусу или, во всяком случае, что-то подобное (в идеале — чтобы человек более никогда не заболел, но как раз таки для этого плацебо не нужно, из-за плацебо человек как раз заболеть может).
Именно в связи с этим вопрос возник. Почему-то склоняюсь к мысли, что это плацебо на третьем этапе нужно для выявления побочек Т.е. если ухудшение/улучшение состояния привитых и контрольной группы коррелируют, то это не побочка, а если привитым в значительной массе стало плохо, а непривитым нет, то это побочка 100%, и изучается сила этих побочек.
Единственное, что мне пришло в голову: что таким образом мы имеем группу привитых людей и как бы контрольную группу гарантированно непривитых и непереболевших ничем, и что можно учитывать за счет этого динамику изменения физического состояния пациентов, ничем не привитых.
Т.е. допустим начались какие-то там ухудшения самочувствия у кого-то из привитых, и чтобы не списать по ошибке отрицательный эффект на лекарство, смотрится по статистике — вот есть контрольная группа, и у 1% ее ухудшилось самочувствие, и у привитых ухудшилось самочувствие тоже у 1%, и обе группы равные по размеру, тогда получается, что с лекарством все ок, это просто статистика.
Так? Или я что-то упускаю?
— момент первого выстрела все равно неизвестен (и направление — откуда — тоже). Все время маневрировать — очень затратно по топливу. Поэтому первый выстрел должен пойти, куда надо.
— маневрирование все же будет не с ускорением 20 км/с^2, а каким-то меньшим, зависит от двигателя. Если какие-нибудь ионные двигатели, которые разгоняют корабль неделями — особо не поманеврируешь.
— с расстояния 1000 км скорость 20 км/с дает максимальное угловое смещение atan(20/1000)=1.15 градуса/сек. Т.е. пушку надо крутить условно на 1 градус в секунду, это не так много. На фоне этого 1 градуса маневры с ускорением в несколько g дадут еще меньшие требуемые углы поворота. Т.е. вопрос в создании системы автоматического прецезионного позиционирования, желательно «по телескопу», чтобы не выдавать себя всякими работающими радарами.
Насколько сейчас это технически возможно — затрудняюсь ответить, но в будущем — почему бы и нет? Какой-нибудь «левитационный» подвес пушки в магнитном поле…
50-100 тысяч километров — там да, конечная скорость света, при маневрировании могут быть проблемы…
Но мощность лазера большую сделать хотя бы теоретически можно (сделаем скидку на технологии будущего), и это оружие достигает цели со скоростью света. Пулю или ракету до околосветовой скорости еще не пойми как разгонять, а тут хотя бы сразу скорость «из коробки».
А вот всякие орбитальные межпланетные полеты, длящиеся годами, и потребность в огромном количестве топлива, или задача сбить 100 мелких дешевых спутников, запустив 100 дорогущих противокосмических ракет размером с Союз или Фалькон — все это выглядит тупиком.
Проще уж тогда врагам сразу денег занести.
Почему-то думается, что бои в космосе, если они вообще произойдут, будут выглядеть так: летят 2 космических аппарата за сотни и тысячи километров друг от друга, далее один из аппаратов режет другой лазером напополам. Или каким-то мощным направленным импульсом выводит из строя всю электронику. Никаких сложных маневров и расходов горы топлива.
Так вот, КЗ длительностью примерно 0.3 с на таком генераторе — он вылетает от защиты по частоте (есть такие сведения о реальных генераторах примерно 1-3 МВт мощностью). Там сильно большого разгона, по идее, и не надо, достаточно включения в противофазе…
И еще заметил — паровыпускной клапан прямо под ногой, может, стоит «паровыхлопную трубу» сделать подлиннее, как у обычного мотоцикла?
Да и «газовыхлопную» трубу можно сделать загнутую назад.
Да, ООП в какой-то степени это сахар для правки кода и как бы поблокового написания.
Удобно, когда толком не знаешь, как все будет работать целиком, но знаешь, как должны работать отдельные куски.
Тогда в ООП-стиле эти куски пишутся (при этом идет обращение к одной структуре с данными), далее додумывается код остальной части программы (в структуру с данными дописываются поля), при этом правка уже написанного минимальная.
mex-файлы — для симулинка, имеется в виду?
Я с симулинком раньше возился-возился, потом проклял его тормознутость, и стал моделировать почти все самописным кодом.
solver.coeff1=k1;
solver.coeff2=k2;
чем запихать в массив coeff=[k1,k2...kn] и скормить функции этот coeff, и дальше его сверху вниз передавать f1(f2(f3(...?
1) имена коэффициентам присвоены. Это удобно, если они разные по физическому смыслу.
2) Внутри функций можно обратиться к коэффициентам по имени.
3) Если захочется добавить новые коэффициенты, то все функции, которые с ними (новыми коэффициентами) не работают, просто остаются, какими были. Дописать коэффициенты «в хвост» — представьте, что они у вас физически разные по смыслу и перемешаются в ходе «апдейтов с дописыванием к концу массива».
2) Ад через точку с запятой в самом начале будет по смыслу совершенно понятными, 1 раз написал и все.
Т.е. вы присваиваете нормальные имена всем переменным, пихаете их в базу данных, дальше внутри функции вытаскиваете по имени все переменные, какие надо. Если толком непонятно, как точно будет устроен код, вы называете по имени все переменные, какие вам кажутся нужными и пишете кусок. Потом еще приписываете кусок. Т.е. код пишется как бы по кускам…
будет как раз кошмар вида coeff=[ад на 10 строчек через запятую].
Нелинейные дифура внутри требуют вычисления подфункций, в них тоже передаются аргументы, так что перепаковывать вот этот массив coeff для скармливания нижестоящему коду будет очень болезненно.
А так, в не-ГУИ приложениях — например, решение нелинейных дифуравнений методом Рунге-Кутты.
Если уравнение приводимо в явном виде к такой форме
dy/dx=f(x,y),
то пишете базу данных EqSolver, куда пихаете все коэффициенты, входящие в функцию f(x,y).
Далее
EqSolver solver=new EqSolver()
solver.coeff1=…
solver.coeff2=…
… так делаете все коэффициенты
1) У вас будет метод f=solver.f(x,y), внутри он будет обращаться к coeff1, coeff2… и возвращать значение
2) У вас будет универсальный метод расчета 1й итерации который вычисляет значение функции f как f=this.f(x,y) вместо f=f(x,y,coeff1,coeff2,,,,)
3) У вас будет универсальный метод, который вызывает в цикле метод расчета одной итерации, в итоге получается массив y по заданному массиву х и начальному значению y_start
При этом во всех методах не нужно будет писать множество аргументов, только что-то типа y=solver.Solve(x, y_start), внутри он вызывает y_next=this.MakeStep(x,y_previous), а MakeStep внутри вызывает f=this.f(x,y).
Статический метод любого другого класса, принимающий этот же объект, в его приватные поля уже залезть не может.