eu_tomat

19 минут назад, Doob сказал:

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

Согласен, для таймера хорошая схема. Для транспозера, конечно, можно сделать лучше.

2 минуты назад, Doob сказал:

Я и не говорил, что нужен второй реактор.

Тут какое-то недопонимание произошло. Про второй реактор ты говорил ранее:

В 28.09.2019 в 15:47, Doob сказал:

Помню, раньше надо было скидывать в другой реактор элементы, которые работали на разгон, чтобы они остыли до рабочей температуры.

И я всё продолжаю спрашивать тебя про использование дополнительного реактора, а ты кидаешь мне схемы на одном реакторе. Вот, я и удивляюсь.

24 минуты назад, Doob сказал:

Вот идеал, к которому надо стремиться:

Скрытый текст

 

Эффективность схемы почти на 35 уровне, пределе. В среднем выдает 611 Eu/t. 139,424,220 Eu за цикл.

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

Но даже это решение не будет идеалом ядерной энергетики, если гнаться за эффективностью. Приближением к идеалу будет полный отказ от теплоотводов в схеме сухого реактора и перенос тепла транспозерами для утилизации в жидкостном реакторе. Это позволит утилизировать как электрическую, так и тепловую энергию топлива. По крайней мере, это будет идеалом для обычного урана. А MOX, если исхитриться, можно будет сжигать в двух реакторах с эффективностью (внезапно!) 1344. Но там работоспособность схемы будет полностью зависеть от микроконтроля на всех этапах работы реактора, а не только на стадии разогрева и в моменты замены топлива.

Возможно, даже эффективность 1344 не будет пределом. Эти реакторы ещё можно тормошить и тормошить. С помощью OpenComputers, разумеется.

15 часов назад, Doob сказал:

P.S. Нашел на форуме IC2 более совершенную схему:

erp=XOtLO+cgw5ngBpMTOPmQcivzrxfR4XwxC4Qp/AZMftJSLk5dumYnK+9C7F2kCCCcAQ==

...

При температуре 9000 выдает 17480 Eu/t, это 486 Eu/t на каждую пачку МОХ. Не совсем рационально расходуется топливо, но зато никаких плясок с бубном - доливай себе редстоун и греби материю ведрами.

Да, хороший результат. Но если кто-то захочет её использовать, то существует упомянутая выше схема от @whiskas на 14% производительнее этой. 4340 eu/t на уране против 3800 eu/t в этой схеме. На MOX получится то же самое соотношение. Конкретное значение выработки зависит от температуры реактора. Позже я надеюсь обсудить в этой теме и алгоритмы быстрого разогрева реактора до теоретически возможного безопасного максимума.

Одно непонятно. Зачем этой схеме реактор отстойник? Или речь шла про другую схему?

15 часов назад, Doob сказал:

Фактически это два реактора, один рабочий, другой - отстойник из одного блока. Я зачем-то сильно намудрил с распределением температуры, поэтому компоненты гонялись туда-сюда.

4 часа назад, Doob сказал:

Я уже подзабыл, неактивные компоненты продолжают просчитываться, если нет прямого контакта?

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

4 часа назад, Doob сказал:

Самый веселый прикол был с редстоуно-лазуритовыми кондеями, с их помощью я придумал как выжать из сухого реактора максимум энергии.

Больше чем эта схема от @whiskas?

4 часа назад, Doob сказал:

Топливом забивался до предела, проводилась постоянная ротация компонентов из трех схем.

А вот, про это попрошу рассказать подробнее. Что за три схемы? Три дополнительных реактора?

4 часа назад, Doob сказал:

Но в один прекрасный момент произошло обновление, кондеи стали опять одноразовые.

Да, печаль. Способ пофиксить сломанные конденасторы в ic2exp уже обсуждался.

4 часа назад, Doob сказал:

Конечно, там добавили инжектор, но он не работал и не крафтился пару лет. Теперь уже два инжектора, для реда один, для лазурита другой.

А зачем нам инжектор, если есть транспозеры?

Ну, что ж, друзья. @Doob, похоже, раскрыл секрет этой схемы.

Для работы теплоотвода требуется лишь наличие тепла в нём. Причём, для эффективного использования теплоотвода, требуется, чтобы количество тепла в нём было не меньше его рассеивающей способности. Иначе теплоотвод будет работать в лучшем случае неэффективно.

Но у заядлых ядерщиков возникает вопрос, откуда возьмётся тепло в теплоотводе, если в теплоотвод тепло не поступает. Зато при жарке картофеля в сковороде таких вопросов ни у кого не возникает. Нижние слои сильно нагреваются и могут пригореть. Верхние слои охлаждаются воздухом и могут сильно остыть, а зимой могут даже заледенеть. Но периодическое помешивание готовящейся картошки позволяет приготовить её равномерно.

Как верно заметил @Doob, транспозер способен менять компоненты как внутри реактора, так и между несколькими реакторами. Теплообменники, распределяющие тепло между компонентами, перестают быть нужными, т.к. тепло можно переносить непосредственно внутри компонентов. И теперь реакторную схему можно составить только из самых эффективных компонентов, приносящих максимальную пользу.

Пользуясь этой идеей, можно посчитать тепловой баланс моей схемы. Она немного греется. Но теперь вы уже догадываетесь, как перевести схему в режим охлаждения, не выключая реактор. Схема вырабатывает 600 eu/t в режиме небольшого перегрева и 540 eu/t в режиме относительного охлаждения. Среднее значение выработки в 558.62 eu/t вычисляется по соотношению времени нагрева и охлаждения реактора.

Реактор не выключается никогда. Лишь тасуются компоненты с некоторой периодичностью. В сундуке лежит запас урана и дополнительный теплоотвод для режима охлаждения.

Какие ещё есть вопросы по этой схеме?

1 минуту назад, monkey сказал:

Нужен приток тепла, а в этой схеме его нет. Что дальше?

Чтобы продвинуться дальше, надо правильно ответить на вопрос.

Приток тепла к теплоотводу является достаточным условием, но не минимальным. Если управлять моей схемой с помощью одного лишь редстоуна, то реактор потребуется иногда отключать. Во время отключения теплоотводы в этой схеме не принимают тепло, но продолжают работать. Они же работают? Потому что, если бы они не работали, то и никакого смысла в фазе охлаждения реактора не было бы. Теплоотводы работают, но приток тепла к ним отсутствует.

Так каково же минимальное и достаточное условие требуется соблюсти для работы теплоотводов?

А у нас на форуме ещё кто-то остался из ядерщиков? Или только я и @Asior?

У меня есть вопрос к тем, кто всё-таки пытается решить эту головоломку. Дать вам следующую подсказку? Или дать время на размышления? Ставьте под этим постом смайлик "Грусть", если нужна подсказка, и смайлик "в шоке", если требуется время. Эти смайлики выбраны из тех, что не влияют на мой рейтинг.

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

Обещаю не останавливаться на одной этой схеме. У меня в запасе есть схемы ещё более безумные и ошеломительные. Я буду чередовать их со схемами попроще, но тоже нужными. Кому интересна ядерка, присоединяйтесь.

18 минут назад, Doob сказал:

Есть операции в модуле bit32 - rshift и lshift, работают в обоих версиях. Только символьные работают почти в два раза быстрее.

Добавлю, что rshift и lshift являются не операциями, а функциями. Поэтому и работать они должны медленнее операторов.

Но, конечно, в современных языках с возможностью перегрузки операторов эта грань довольно тонка.

Я забыл прокомментировать этот момент:

14 часа назад, Asior сказал:

Так, запуск прогнал, это было довольно занимательно если б не пластины то была бы еще одна дырка на карте. Хотя нет, дырка теперь уже есть. 

Этого следовало ожидать. Я выложил лишь одну схему, без обвязки, без скрипта, без описания. Использованные тобой пластины способны лишь ненадолго отстрочить неизбежное. А надо попытаться отсрочить еще сильнее, постепенно доводя срок до бесконечности. Но не отключая реактор. Отключенный реактор будет простаивать, а схема нацелена на его максимальную эксплуатацию: если сборка, то счетверённая, и если теплоотвод, то разогнанный. И никаких пустых слотов – это преступление против экономики, как и отключение реактора.

Не надо ждать милости от админов, ограничивающих количество реакторов в привате. Надо повысить производительность уже имеющихся реакторов до предела. И поможет нам в этом только OpenComputers. И знания, конечно, в них вся сила.

13 часа назад, Asior сказал:

Хмм, щас попробовал выкинуть с 1 стержня все куллеры, и удивительно, но оно не нагревается. Правда греться стали другие куллеры, но возникает вопрос, как это вообще так?

Если сборка стержней контактирует с какими-либо принимающими тепло элементами, то всё тепло она передаст на них, распределяя его равномерно между ними. В противном случае всё тепло сборка передаст на корпус реактора. Такова механика. Тепло с корпуса реактора могут забрать некоторые виды теплообменников и теплоотводов. Теплообменники (не все) могут принять тепло с корпуса, если их температура ниже температуры корпуса. А теплоотвод охлаждает корпус, даже ценой повышения собственной температуры; он подобен морозильнику, забирающему тепло у и без того холодных продуктов.

Поэтому, когда ты убрал кулеры вокруг одного из ТВЭЛ'ов, тепло через корпус ушло на другие, ранее незадействованные. Да и на задействованные тоже ушло, с этой механикой мы попробуем разобраться позже. Своим экспериментом ты воспроизводишь ситуацию из наводящего вопроса. Теплоотводы могут работать даже не прикасаясь к ТВЭЛ'ам. И для того, чтобы они работали, достаточно лишь одного условия.

Каково же минимальное условие для того, чтобы теплоотвод отводил тепло в атмосферу?

5 минут назад, Asior сказал:

Данная схема работает только под контролем ОС и никак иначе.

Совершенно верно. OC в этой схеме играет ключевую роль.

5 минут назад, Asior сказал:

Ну или на системе таймеров.

Таймеры тут не помогут. У таймеров нет всех возможностей OC. И это тоже намёк на разгадку. Но с этой стороны будет трудно зайти без подготовки. Есть более логичный вход.

9 минут назад, Asior сказал:

Всмысле в каждой позиции работают? Не работают они, вообще никак.

А это возвращает нас к наводящему вопросу. В предварительно разогретом реакторе разогнанные телоотводы работают даже не касаясь ТВЭЛ'ов. И работают они потому что...

Почему же  они работают?

Я позволю себе сохранять интригу, чтобы не лишать других участников удовольствия решить эту головоломку.

1 час назад, Asior сказал:

Все куллеры что черные, тоесть они не работают, заменил на реакторные пластины, чтоб добавить себе немного времени на реакцию (в случае аварии чтоб успел снести контроллер).

Вырабатывает данная схема 600Eu/t максимальное время работы 66 секунд, время охлаждения 40 секунд.

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

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

Даю наводящий вопрос: почему планировщик перестаёт подкрашивать фон кулеров чёрным, если задать стартовую температуру реактора?

Ах, да. Нагляднее же можно сделать:

$ echo 'print( (100500>>8) & 0xff )' | lua5.3
136
$ echo 'print( (100500>>8) & 0xff )' | lua5.2
lua5.2: stdin:1: unexpected symbol near '>'

@Natt Похоже, приведённый код запущен в Lua5.2, там нет операций сдвига. В Lua5.3 должно работать.

$ lua5.3
Lua 5.3.1  Copyright (C) 1994-2015 Lua.org, PUC-Rio
> = (100500>>8) & 0xff
136

$ lua5.2
Lua 5.2.4  Copyright (C) 1994-2015 Lua.org, PUC-Rio
> = (100500>>8) & 0xff
stdin:1: unexpected symbol near '>'

Тема микроконтроля ядерных реактров уже всплывала на форуме. Например, периодическое отключение и включение ядерного реактора  является простейшей формой микроконтроля. Выполнять его можно и вручную, и с помощью компьютера, и с помощью мода NuclearControl. Есть и более интересные применения микроконтроля реакторов. Например, здесь и здесь.

Кстати, кому-нибудь удалось разобраться, при каких условиях работает эта схема?

Приветствую всех любителей ядерки в индастриале!

Это экспериментальная тема. В ней я предлагаю делиться своими мыслями о микроконтроле ядерных реакторов с помощью OpenComputers и совместными усилиями найти интересные решения.

У меня есть ряд идей по теме, есть даже условно рабочие скрипты, но нет времени на то, чтобы обкатать эти идеи в различных условиях, доработать скрипты, и выложить подробный гайд, хотя и кусок гайда тоже имеется. А времени на доработку сейчас нет и пока не предвидится. Поэтому я планирую постепенно выкладывать различные идеи, куски гайдов, скрипты, слушать критику и встречные идеи. Не исключаю, что у кого-то есть идеи получше моих.

Если какая-то идея будет достаточно разобрана в дискуссии, я попробую скомпилировать обсуждение в микрогайд, и опубликовать его отдельным постом. Ссылку на микрогайд я добавлю в шапку темы. Также написать микрогайд сможет любой желающий, желательно в этой теме. Ссылку я также добавлю. Если я вдруг забуду добавить, напомните мне кто-нибудь, можно прямо в этой теме.

Что нам может дать этот формат? С одной стороны, сохранится живость и непринуждённость общения. Мы можем выражать мысли, как удобно каждому из участников. А с другой, мы можем фиксировать наши мысли в удобном для читателей виде. Кому-то покажется достаточным быстренько пройтись по ссылкам из шапки. А если гайды окажутся недостаточно ясными, читатель может внимательно почитать дискуссию и понять происхождение тех или иных выводов. Также всегда можно задать вопрос и возобновить обсуждение, а по результатам дополнить тот или иной гайд. Или даже добавить новый.

Ещё одно замечание: я настаиваю на микрогайдах и ссылках на них из шапки. Одна идея – один микрогайд. Это упрощает чтение, особенно для тех, кто плохо знает предмет. Если тема разрастётся, а гайды так и не будут написаны, я планирую размещать ссылки на просто интересные мысли. Опять же, не возбраняется напомнить мне об этом.

Что такое микроконтроль ядерных реакторов Industrial Craft и зачем он нужен?

@ArtHacker Oracle в своём репертуаре. Видимо, хотят сделать платной и jdk тоже. Просто забей.

Забей туда левую инфу и качай, что тебе нужно. Я сам так скачивал.

3 минуты назад, ArtHacker сказал:

это ты тему про ocelot создал из-за скандалов происходящих тут?

Кажется, я что-то пропустил. Кинь, пожалуйста, ссылки на скандалы.

9 минут назад, Totoro сказал:

Можно подумать над тем, какие именно инструменты могут понадобиться - какой-нибудь дебаггер-профайлер... хз.

При программировании тяжёлых вычислений вроде шифрования RSA профайлер очень бы пригодился. Судя по описанию, тайминги в этом эмуляторе обещают очень точно соответствовать таймингам в игре.

35 минут назад, Zer0Galaxy сказал:

В онлайн версии попытка выйти из редактора edit по Ctrl+W приводит к закрытию страницы

В 14.09.2019 в 15:27, Totoro сказал:

* В редакторе edit кнопка выхода заменена на Ctrl + E. Стандартная комбинация юзается браузером для закрытия вкладок - и переопределить её нельзя по соображениям безопасности.

@serafim А какой смысл дублировать на pastebin? Там же всё есть в репозитории.

Я тоже проверю свои телепатические способности. Речь, скорее всего, идёт об этой программе:

https://github.com/ATastyPeanut/OpenComputers-Minecraft-Lua/blob/master/Ticks-Second-Tools/TPS-Holo-Display.lua

Картинка тоже нашлась.

17 минут назад, HeroBrine1st сказал:

На картинке ниже (это из PDF) я нашел две переменные, которые нигде не определены и по названию не совсем понятно, как их вычислять (j - вообще не указано, e_i - тоже как-то не понятно, да и зачем там r на 1 умножать?):

j это длина экспоненты в битах, i индексирует биты. e_j - это очередной бит экспоненты. В Си-подобных языках нумерация выполняется в диапазоне [0..n-1] в отличие от [1..n] в Луа.

Единицу на r умножать не надо, такая запись применена для наглядности: сначала получаем n-остаток исходного числа и n-остаток единицы, затем выполняем серию умножений по Монтгомери, а на последнем шаге выполняем обратное преобразование результирующего n-остатка через фиктивное умножение Монтгомери.

7 часов назад, HeroBrine1st сказал:

Занялся я тут алгоритмом.

Алгоритмом умножения Монтгомери, насколько я понимаю. Прошу сразу уточнять такие детали. А то до этого мы говорили об алгоритмах выбора оптимального размера блока, и вдруг внезапно появляется "Алгоритм".

Повторюсь:

В 26.08.2019 в 09:47, eu_tomat сказал:

В статье введено понятие n-остатка. И умножение Монтгомери работает не с исходными числами, и с их n-остатками. То есть, сначала числа преобразуются в их n-остатки, которые затем перемножаются по алгоритму Монтгомери. На выходе процедуры умножения также получается n-остаток. И для последующей работы его требуется преобразовать в исходную форму.

В твоём же коде print(mon_pro(a_n, b)). Во-первых, вторым аргументом нужно подавать не b, а также его n-остаток. Во-вторых, результат умножения требует обратного преобразования.

55 минут назад, Asior сказал:

По коду, рекомендую составить запрос в соответствующую тему. Нужна программа и прочее прочее.

Если это заказ на программу, то и эту тему можно перенести, не создавая новую. Только первый пост надо немного поправить.

3 часа назад, HeroBrine1st сказал:

Собственно, библиотека. metaint имеет основание 10^7, т.е. 10 в этой системе = 10^7, а 010 попросту не появляется - все нули с конца массива отсекаются (библиотека пишет число справа налево).

3 часа назад, HeroBrine1st сказал:

Или логарифмы. посмотрю там.

Да, можно логарифмами. При основании 10^7 каждый разряд числа кроме старшего кодирует log2(10^7)=23.25349 бит информации. Количество бит, кодируемых старшим разрядом, равно логарифму его значения по основанию два. Например, если разряды числа хранятся в таблице, и при этом не хранятся ведущие нули, то максимальное количество шифруемых бит будет равно log2(10^7)*(#t-1) + log2(t[#t]).

И, кстати, при генерации простых чисел p и q тоже надо стремиться к выбору чисел из верхнего диапазона, как этого сделано в openssl. Там при хранении числа с необрезанными ведущими нулями старший байт всегда имеет ненулевое значение. Можно было бы и в этой библиотеке при генерации использовать фильтр, чтобы старший разряд всегда превышал некоторое значение. Если попытаться обрезать ведущие нули у такого числа, то обрезать там будет попросту нечего.

А ещё нужно помнить, что с каждым отрезанным разрядом падает фактическая длина ключа, что сказывается на его криптостойкости. В openssl больше 7 бит никогда не отрезается от длины ключа. Может, и ещё меньше, я не проверял.

3 часа назад, HeroBrine1st сказал:

Наверное, проще будет добавить поддержку настоящих форматов ключей, а там просто по длине base64 вычислять битовую длину.

А это было бы очень интересно. Не все видят смысл в генерации ключей именно этой библиотекой, да и генерируются они неприлично долго. Шифрование, конечно, тоже тормозит, но его алгоритм гораздо проще, что позволит относительно небольшими усилиями оптимизировать его до предела.