например, в when2meet опрос на произвольную неделю должен быть в строго определённом часовом поясе и не будет подгоняться к пользовательскому/выбранному, потому что ответ зависит от даты; для конкретных дат конвертация поясов работает очень удобно
Если выбрать определённую неделю (скажем, 7-11 июля 2025) или диапазон дат другой длины, то сервис всё конвертирует, т.е. данные внесены.
А вот если выбрать произвольную неделю (чтобы назначить день недели и время на весь год), то фиксированное местное время в одной локации будет соответствовать нескольким разным местным временам в (некоторых) других локациях в разные даты. Часто это плюс/минус час, но для некоторых пар может накапливаться и больше. Тут не очевидно, как это даже отображать в интерфейсе — например, показывать отдельную сетку дней недели + времён для каждой из разных разниц во времени? Обрабатывать результаты опроса может быть ещё сложнее.
Ну, по долготе всё равно как минимум синус широты нужен, не очевидно, что дополнительный множитель (причём только если начинать с угловых минут) так уж мешает. Мне кажется, что скорее всё же дело привычки.
Если вы серьёзно, то как, по-вашему, решить эту задачу ради клиентов с учётом меняющихся сдвигов местного времени в течение года (по-разному в разных местах)? Более очевидный пример — где-то используют летнее/зимнее время, а где-то сдвиг от UTC фиксированный (не столь важно, на зимнем или летнем). Менее очевидный — разные даты перехода на летнее время и обратно (например, в Европе и Северной Америке). А when2meet — ещё и бесплатный сервис.
Поскольку морская миля имеет физический смысл. В отличии от метра. Если считать метр не 1\40 000 000 а 1\40 000 100 частью меридиана, то ничего не изменится. С милей - не получится.
Под "физическим" смыслом морской мили вы подразумеваете изначальное определение через длину одноминутной дуги большого круга на поверхности Земли? Но сейчас морская миля определяется как ровно 1852 метра, потому что Земля не сферическая и длина минуты меридиана колеблется между примерно 1843 и 1862 метров у полюсов и у экватора соответственно.
Кроме того, чем минута (т.е. 1/180/60 от полукруга) принципиально лучше, чем 1/40 000 000 (хотя и метр уже не совсем так определяется)?
Самая дурацкая вещь в метрической системе - метр, как ни странно. Абсолютно искусственная величина. К которой за уши притянуто всё остальное.
Кажется, что единицы измерения — скорее всё же дело привычки, потому и значение метра (и прочих метрических единиц) стараются держать почти точно таким же при переопределениях.
Самое неудобное - множитель пересчёта 12.
Встречал и аргументы в пользу множителя 12 — мол, так удобнее делить на 3, 6 и 12, что вроде не так редко нужно; может, даже чаще, чем на 5 и 10. Хотя, может быть, это циклический аргумент: любителям дюймов и футов кажется важнее делить на 3 и т.д., а привыкшим к десятичным единицам — на 5, 10 и т.д.
Специально поставили телескоп в высокогорной пустыне — меньше атмосферы, сухо, относительно стабильная погода. Южный Полюс ещё хорош, хотя туда сложнее доставлять и добираться, чем в Чили, и небо над головой одно и то же (а под большими углами к вертикали больше атмосферы на пути).
А они спектр не измеряют, только, условно говоря, RGB, единичные количества составляющих спектра?
При получении спектра свет разделяется на большее количество категорий и потому точность становится меньше для того же объекта и продолжительности наблюдения. Так что, скорее всего, не получилось бы достаточно большое количество качественных спектров вместе с достаточно частым повторением обзора неба. Последнее критично для мониторинга быстрых, "преходящих" астрономических явлений вроде сверхновых (в т.ч. типа Ia), гамма/радио-всплесков и событий приливного разрушения. Кроме того, качественные "изображения" служат для выбора целей для последующих спектроскопических наблюдений.
Ещё бы рассказали, как и где эти данные сохраняются, сколько их, что там используют для сжатия.
Насчёт этого я особо не знаю, кроме того, что доступно в Википедии.
Базовые часовые пояса ещё не так страшны — можно худо-бедно определить по локации, какой нужен. Более серьёзная проблема возникает тогда, когда они меняются.
Особенно регулярные скачки между летним и зимним временем, которых в одних местах нет, а в других переходы происходят в разные дни и/или разное время дня. В результате время созвона нельзя назначить фиксированным во всех часовых поясах на весь год (и, например, в when2meet опрос на произвольную неделю должен быть в строго определённом часовом поясе и не будет подгоняться к пользовательскому/выбранному, потому что ответ зависит от даты; для конкретных дат конвертация поясов работает очень удобно). Кроме того, переходы приводят к несуществующим или повторяющимся комбинациям даты и времени (по крайней мере, без достаточно полной маркировки для разгадки часового пояса).
Вы как-то перевели речь с момента импульса противовеса на момент импульса планеты/планетоида. Понятно, что второй намного больше и о нём можно практически не беспокоиться, пока не идёт речь о выводе значительной доли массы.
Хм, если даже противовес и будет терять момент импульса, то на него действительно вроде бы можно подавать топливо с поверхности вдоль троса. Только тут надо думать ещё о прочности трубопровода, и поднимающееся вдоль лифта топливо будет тоже откуда-то забирать момент импульса (вот зараза!). Правда, если топливо потом выбрасывать назад намного быстрее скорости вращения (например, из реактивного или ионного двигателя), то оно сможет сообщить больше момента импульса системе противовеса и тросов.
Кстати, для достижения второй космической на Церере достаточно лифта до радиуса 1500 км (вместо 1200 км для синхронной орбиты), т.е. около 1000 км троса с поверхности. Правда, тогда у отпущенного груза не останется скорости на бесконечности, и поэтому может иметь смысл набрать больше. На удалении 30 тыс. км вращательная скорость будет почти 5.8 км/с, и она уже практически не убудет после выхода из гравитационной ямы Цереры. С другой стороны, непонятно, как потом менять направление той скорости для манёвров без сравнимого или даже большего количества топлива, чем нужно для её набора с нуля. Так что мотивация для 30 тысяч километров по-прежнему не ясна.
Но вот между синхронной орбитой и 30 тыс. км при постоянной толщине стального троса набегает разница механических напряжений в 260 ГПа (гигапаскалей), почти в тысячу раз больше, что уже катастрофически много. Вряд ли даже нанотрубки справятся без переменной толщины.
в случае с Церерой вовсе необязательно извращаться с переменной толщиной, там и обычный стальной трос выдержит
Стало интересно проверить. Если у троса постоянная площадь сечения A, а не переменная (для которого приведено решение в моём другом комментарии), то сила натяжения меняется только за счёт механического напряжения, и имеем
площадь сечения сокращается, и мы получаем перепад механического напряжения
Радиус Цереры грубо 470 км. Масса кг, период 9.1 часов, откуда радиус синхронной орбиты примерно 1200 км (снова вопрос, откуда 30 тысяч км в статье, ну да ладно). С учётом плотности стали 7900 кг/м3, перепад механических напряжений между поверхностью и синхронной орбитой будет около 290 МПа (мегапаскалей). Это почти равно пределу прочности обычной стали (согласно Википедии), которую такой нагрузке подвергать вряд ли безопасно (а ещё нужно выдерживать вес лифта). Однако вроде бы есть рессорно-пружинная сталь с прочностью в 5 раз выше, она может сработать.
Не знаю, зачем так заморачиваться и думать ещё о натяжении троса, это вообще никакой роли не будет играть.
По-моему, лучше всё-таки подумать, чем просто поверить, что всё работает. При отклонении троса от вертикали от противовеса сила натяжения ещё будет менять его вращательную скорость.
Но вообще мои сомнения скорее про устойчивость не стационарного положения (без атмосферы), когда кабина не движется, а при собственно использовании лифта по назначению. Буквально как бы момент импульса противовеса не оказался исчерпаемым ресурсом, расходуемым на подъём грузов на орбиту (и компенсацию сопротивления атмосферы), и не пришлось время от времени разгонять или заново запускать противовес традиционными методами (например, реактивным двигателем).
Ну, у Цереры атмосферы практически нет. Но сценарий добычи ресурсов с поверхности подразумевает результирующий поток грузов вверх по лифту. Как минимум в некоторых вариантах космических лифтов подразумевается, что потоки грузов вверх и вниз компенсируют друг друга, из-за чего можно минимизировать даже расход энергии. Может быть, что схема с тросами и противовесами (неявно) подразумевает именно такой сбалансированный случай.
Аналогия с резинкой (или просто ниткой/верёвкой) неполная. Во-первых, в ней нет аналога кабины лифта, которая бы набирала момент импульса. (Да и противовес вы тоже не описали.) Во-вторых, в тросовом космическом лифте максимальное натяжение не в точке крепления к планете/планетоиду, а на стационарной орбите.
Нет, потому что открытый и свободный контент бесплатен. Лицензия указывает, что получатель не обязан ничего платить за коммерческое использование открытого контента и открытых данных.
Я имел в виду пользу для имиджа, которую потом в некоторых местах можно материализовать, например, через кампании против урезания бюджета, за увеличение государственного финансирования и/или по сбору частного.
Нет, потому что доступ уже обеспечен веб-сайтами научных учреждений. Вся задача сводится к тому, чтобы переключить эти веб-сайты из режима «магазин по продаже контента» в режим «свободный источник контента».
Я с таким не сталкивался на сайтах российских научных учреждений. Подумал, что именно обсерватории могут иначе работать, или ситуация недавно изменилась, но тоже не похоже. Зашёл на несколько вебсайтов обсерваторий и не нашёл "магазина по продаже контента", всё больше новости с иллюстрациями или галереи с непонятной лицензией (по умолчанию, видимо, несвободной), хорошо если написано, к кому обращаться, если вдруг что.
Готовый магазин для более полных научных/технических данных (чем изображения) кажется ещё менее вероятным, потому что вещь очень уж нишевая. Заранее заморочиться с хостингом гигабайтов/терабайтов/петабайтов, или сделать специальную пробную версию поменьше ради единичных потенциальных покупателей? А если уж по грантам давать доступ не требуется, и не предвидится прочих преимуществ, то этим почти наверняка не будут заниматься.
Так закрытый контент российских обсерваторий продаётся лучше (может профинансировать сколь-нибудь значительную долю их работы), или это скорее тот случай, когда жалко терять сугубо потенциальную прибыль?
Правда, думается, что в России ещё и вряд ли возможно получить больше государственного или частного финансирования именно за открытые изображения и другие данные. Тогда и от свободного лицензирования обсерватории существенно лучше не станет, а обеспечение доступа нередко ещё и требует дополнительных усилий.
Когда лифт не движется и сопротивлением воздуха можно пренебречь, по тросу в равновесном состоянии момент импульса течь не должен.
Вроде бы течение момента импульса по тросу может обеспечить только разница сил натяжения вдоль троса. Поскольку от поверхности до синхронной орбиты сила натяжения возрастает, "точка подвеса" на синхронной орбите для этого должна быть сдвинута от поверхности (немного) вперёд, т.е. по направлению вращения. А поскольку дальше до противовеса она убывает, то противовес должен быть сдвинут (чуть-чуть) назад (против направления вращения) относительно "точки подвеса" на синхронной орбите, если нам нужно подавать момент импульса в ту дальнюю часть троса тоже. Это довольно хитрая конструкция, и не очевидно, как и почему именно она образуется.
Тут возникает вопрос, насколько хорошо у российских обсерваторий получается монетизировать свои изображения (вероятно, риторический, но мало ли).
Открытые данные (в конечном итоге) вроде бы являются практически стандартом для больших научных проектов, финансируемых из бюджетных средств в США, Западной Европе и Канаде. Хотя они не обязательно становятся доступны сразу — поначалу бывает и проприетарный период "только для своих", чтобы мотивировать людей работать над инструментом и первичной обработкой данных, а не только лишь использовать готовые.
Да, кстати, толщина троса будет неодинаковой - ведь ему надо поддерживать центробежную собственную массу, вес которой увеличивается при приближении к поверхности. Я бы хотел глянуть на эти адские эпюры расчета прочности троса от расстояния до тела.
Была у нас вроде бы такая школьная олимпиадная задача с упрощённой постановкой (хотя, наверное, она больше годится для университета, чтобы знали начала матана и немного диффуров).
Прочность на растяжение/сжатие — это предел механического напряжения, силы на единицу площади (как давление, но смысл не совсем тот). Можно установить фиксированное механическое напряжение во сколько-то раз меньше предела прочности для надёжности. Изменение силы натяжения (в случае троса) или давления (в случае штанги/башни) должно компенсировать гравитационную и центробежную силы, действующие на участок конструкции. Получается такой диффур:
где A — площадь сечения троса/штанги, — выбранное механическое напряжение, — плотность материала, R — расстояние от центра планеты/планетоида, — угловая скорость вращения (предполагая строительство на экваторе). В случае штанги нужно выбирать знак плюс, в случае троса — минус. Решение довольно простое:
Минимальная площадь сечения определяется так, чтобы материал выдержал максимально нагруженную кабину лифта, а в случае троса — ещё и противовес на том конце.
В земных условиях для нормальных материалов максимальная площадь сечения получается очень уж огромной, нужно минимизировать отношение плотности к дозволительному напряжению (пределу прочности).
В процессе подъёма на синхронную орбиту кабина должна приобрести момент импульса. Ну, угловая скорость сохраняется, но момент инерции кабины вокруг оси вращения планеты/планетоида растёт как .
В случае жёсткой штанги/башни вроде более-менее понятно, что вся конструкция может "забирать" момент импульса у планеты/планетоида, хотя для этого нужна приличная прочность на изгиб (но вроде бы не настолько сильная, как на сжатие/растяжение, т.к. когда лифт не движется, всё раскручено до правильных скоростей и изгибаться не надо).
В случае троса/системы тросов не очевидно. Казалось бы, из-за изгиба троса около кабины против направления вращения силы натяжения троса (как снизу, так и сверху) будут подтягивать кабину в направлении вращения. Соответственно, момент импульса вроде бы будет "течь" к кабине не только снизу, но и сверху. Снизу не проблема, потому что даже у карликовой планеты момента импульса очень много (по крайней мере, пока мы не начинаем поднимать грузы, сравнимые с массой планеты, при этом всё спускаемое можно вычитать). Но сверху только противовес по большому счёту, как ему не потерять момент импульса и соответственно не начать снижаться и/или тормозить?
До тех пор, пока материя не рекомбинировалась, у материи вообще не было возможности сжиматься. Положительно заряженные ионы обуславливали равномерное распределение вещества повсеместно. При равномерно распределенной материи, гравитация со всех направлений, в пределах погрешности, равнялась нулю.
Скорее уж огромное (релятивистское) давление фотонов, очень часто взаимодействующих с обычной материей (в основном электронами, которые уже взаимодействовали с положительными ионами), мешало гравитационному коллапсу.
А в стандартной космологической парадигме есть ещё и тёмная материя, которая потихоньку сжималась в это время, потому что на неё фотоны влияли намного слабее. Это сжатие было очень медленным, пока в энергетическом бюджете Вселенной доминировало излучение, и стало побыстрее, когда стала преобладать материя (тёмная+обычная). Считается, что после рекомбинации обычная материя стала проваливаться в потенциальные ямы, сформированные тёмной материей, иначе рост структур был бы существенно медленнее.
В уравнение Фридмана для ускорения они входят в комбинации 𝜀 + 3𝘱, поэтому только Λ-член дает ускоренное расширение.
Причём ускорение в смысле второй производной масштабного фактора a, . Если рассматривать относительную скорость расширения (она же параметр Хаббла) , то её производная не возрастает даже с космологической постоянной, для этого нужно нечто ещё более экстремальное с , что вроде как нарушает null energy condition и ломает многое в квантовых теориях поля.
Сам квадрат параметра Хаббла, согласно другому уравнению Фридмана, просто пропорционален суммарной плотности (в которую нужно включить глобальную кривизну пространства, если она есть).
Очень интересно, как это работает. Большинство современных языков программирования вообще собираются одной командой - по крайней мере, иное мне не встречалось - и в таком случае Make надо заменять собой компиляторы всех языков мира, и все это должно быть написано вручную.
Насколько я понимаю, make только парсит уже прописанные зависимости, в самом коде он специально не разбирается. Т.е., например, если зависимость от какого-то включённого (#include в C/C++) файла явно не написана, то после его изменения (без модификации основного файла) перекомпиляция не произойдёт, хотя по логике она нужна. Однако как минимум в gcc/g++ и clang есть опция -MMD, которая как раз генерирует такие неочевидные зависимости для make параллельно с компиляцией, и получившийся файл можно включить в Makefile.
А последнее вещь крайне сомнительная. Не отрицаю, что вычислять хеш каждого файла было бы несколько накладно, не говоря уже про то, чтобы хранить это, но очень много какие программы творят с датами дичь. Проводник Windows, например, при распаковке архивов время создания ставит на время распаковки. Это конкретно тут не особо навредит, просто первый пришедший в голову пример. По сути, один скрипт на Python, меняющий даты файлов на более старые, чем последняя сборка, и все сломано.
С продвинутыми зависимостями дата изменения работает весьма хорошо, и позволяет сэкономить время на не изменённых частях больших проектов. А на крайний случай есть make clean, который должен удалять все результаты компиляции, после него make будет собирать всё заново.
Но если в проекте мало файлов, не нужно выискивать системные библиотеки, аккуратно выставлять опции компилятора и всё такое, то, наверное, можно хорошо обойтись и без make.
P.S. Я как-то написал проверку необходимости сборки (подобно make) для пошаговой обработки файлов данных на Python (потому что у меня рецепты были функциями на Python, и имена файлов я там же генерировал). Сначала тоже использовал дату изменения, но потом понял, что это не подходит, потому что я иногда подставляю более старый файл. Так что перешёл на хэши, и с не слишком большим количеством и размером файлов они работают хорошо.
Кажется, я не очень ясно сформулировал.
Если выбрать определённую неделю (скажем, 7-11 июля 2025) или диапазон дат другой длины, то сервис всё конвертирует, т.е. данные внесены.
А вот если выбрать произвольную неделю (чтобы назначить день недели и время на весь год), то фиксированное местное время в одной локации будет соответствовать нескольким разным местным временам в (некоторых) других локациях в разные даты. Часто это плюс/минус час, но для некоторых пар может накапливаться и больше. Тут не очевидно, как это даже отображать в интерфейсе — например, показывать отдельную сетку дней недели + времён для каждой из разных разниц во времени? Обрабатывать результаты опроса может быть ещё сложнее.
Ну, по долготе всё равно как минимум синус широты нужен, не очевидно, что дополнительный множитель (причём только если начинать с угловых минут) так уж мешает. Мне кажется, что скорее всё же дело привычки.
Если вы серьёзно, то как, по-вашему, решить эту задачу ради клиентов с учётом меняющихся сдвигов местного времени в течение года (по-разному в разных местах)? Более очевидный пример — где-то используют летнее/зимнее время, а где-то сдвиг от UTC фиксированный (не столь важно, на зимнем или летнем). Менее очевидный — разные даты перехода на летнее время и обратно (например, в Европе и Северной Америке). А when2meet — ещё и бесплатный сервис.
Под "физическим" смыслом морской мили вы подразумеваете изначальное определение через длину одноминутной дуги большого круга на поверхности Земли? Но сейчас морская миля определяется как ровно 1852 метра, потому что Земля не сферическая и длина минуты меридиана колеблется между примерно 1843 и 1862 метров у полюсов и у экватора соответственно.
Кроме того, чем минута (т.е. 1/180/60 от полукруга) принципиально лучше, чем 1/40 000 000 (хотя и метр уже не совсем так определяется)?
Кажется, что единицы измерения — скорее всё же дело привычки, потому и значение метра (и прочих метрических единиц) стараются держать почти точно таким же при переопределениях.
Встречал и аргументы в пользу множителя 12 — мол, так удобнее делить на 3, 6 и 12, что вроде не так редко нужно; может, даже чаще, чем на 5 и 10. Хотя, может быть, это циклический аргумент: любителям дюймов и футов кажется важнее делить на 3 и т.д., а привыкшим к десятичным единицам — на 5, 10 и т.д.
Специально поставили телескоп в высокогорной пустыне — меньше атмосферы, сухо, относительно стабильная погода. Южный Полюс ещё хорош, хотя туда сложнее доставлять и добираться, чем в Чили, и небо над головой одно и то же (а под большими углами к вертикали больше атмосферы на пути).
Rubin не измеряет спектры, только "изображения" — суммарное количество света через каждый из 6 "цветовых" фильтров, 5 из которых могут работать одновременно (в одну и ту же ночь).
При получении спектра свет разделяется на большее количество категорий и потому точность становится меньше для того же объекта и продолжительности наблюдения. Так что, скорее всего, не получилось бы достаточно большое количество качественных спектров вместе с достаточно частым повторением обзора неба. Последнее критично для мониторинга быстрых, "преходящих" астрономических явлений вроде сверхновых (в т.ч. типа Ia), гамма/радио-всплесков и событий приливного разрушения. Кроме того, качественные "изображения" служат для выбора целей для последующих спектроскопических наблюдений.
Насчёт этого я особо не знаю, кроме того, что доступно в Википедии.
Базовые часовые пояса ещё не так страшны — можно худо-бедно определить по локации, какой нужен. Более серьёзная проблема возникает тогда, когда они меняются.
Особенно регулярные скачки между летним и зимним временем, которых в одних местах нет, а в других переходы происходят в разные дни и/или разное время дня. В результате время созвона нельзя назначить фиксированным во всех часовых поясах на весь год (и, например, в when2meet опрос на произвольную неделю должен быть в строго определённом часовом поясе и не будет подгоняться к пользовательскому/выбранному, потому что ответ зависит от даты; для конкретных дат конвертация поясов работает очень удобно). Кроме того, переходы приводят к несуществующим или повторяющимся комбинациям даты и времени (по крайней мере, без достаточно полной маркировки для разгадки часового пояса).
Про такие хитрости была очень интересная статья на Хабре: https://habr.com/ru/companies/ruvds/articles/856780/
По-видимому, опечатка перекочевала из источника; Londonberry действительно не гуглится и исправляется на Londonderry.
Вы как-то перевели речь с момента импульса противовеса на момент импульса планеты/планетоида. Понятно, что второй намного больше и о нём можно практически не беспокоиться, пока не идёт речь о выводе значительной доли массы.
Хм, если даже противовес и будет терять момент импульса, то на него действительно вроде бы можно подавать топливо с поверхности вдоль троса. Только тут надо думать ещё о прочности трубопровода, и поднимающееся вдоль лифта топливо будет тоже откуда-то забирать момент импульса (вот зараза!). Правда, если топливо потом выбрасывать назад намного быстрее скорости вращения (например, из реактивного или ионного двигателя), то оно сможет сообщить больше момента импульса системе противовеса и тросов.
Кстати, для достижения второй космической на Церере достаточно лифта до радиуса 1500 км (вместо 1200 км для синхронной орбиты), т.е. около 1000 км троса с поверхности. Правда, тогда у отпущенного груза не останется скорости на бесконечности, и поэтому может иметь смысл набрать больше. На удалении 30 тыс. км вращательная скорость будет почти 5.8 км/с, и она уже практически не убудет после выхода из гравитационной ямы Цереры. С другой стороны, непонятно, как потом менять направление той скорости для манёвров без сравнимого или даже большего количества топлива, чем нужно для её набора с нуля. Так что мотивация для 30 тысяч километров по-прежнему не ясна.
Но вот между синхронной орбитой и 30 тыс. км при постоянной толщине стального троса набегает разница механических напряжений в 260 ГПа (гигапаскалей), почти в тысячу раз больше, что уже катастрофически много. Вряд ли даже нанотрубки справятся без переменной толщины.
Стало интересно проверить. Если у троса постоянная площадь сечения A, а не переменная (для которого приведено решение в моём другом комментарии), то сила натяжения меняется только за счёт механического напряжения, и имеем
площадь сечения сокращается, и мы получаем перепад механического напряжения
Радиус Цереры грубо 470 км. Масса
кг, период 9.1 часов, откуда радиус синхронной орбиты примерно 1200 км (снова вопрос, откуда 30 тысяч км в статье, ну да ладно). С учётом плотности стали 7900 кг/м3, перепад механических напряжений между поверхностью и синхронной орбитой будет около 290 МПа (мегапаскалей). Это почти равно пределу прочности обычной стали (согласно Википедии), которую такой нагрузке подвергать вряд ли безопасно (а ещё нужно выдерживать вес лифта). Однако вроде бы есть рессорно-пружинная сталь с прочностью в 5 раз выше, она может сработать.
По-моему, лучше всё-таки подумать, чем просто поверить, что всё работает. При отклонении троса от вертикали от противовеса сила натяжения ещё будет менять его вращательную скорость.
Но вообще мои сомнения скорее про устойчивость не стационарного положения (без атмосферы), когда кабина не движется, а при собственно использовании лифта по назначению. Буквально как бы момент импульса противовеса не оказался исчерпаемым ресурсом, расходуемым на подъём грузов на орбиту (и компенсацию сопротивления атмосферы), и не пришлось время от времени разгонять или заново запускать противовес традиционными методами (например, реактивным двигателем).
Ну, у Цереры атмосферы практически нет. Но сценарий добычи ресурсов с поверхности подразумевает результирующий поток грузов вверх по лифту. Как минимум в некоторых вариантах космических лифтов подразумевается, что потоки грузов вверх и вниз компенсируют друг друга, из-за чего можно минимизировать даже расход энергии. Может быть, что схема с тросами и противовесами (неявно) подразумевает именно такой сбалансированный случай.
Аналогия с резинкой (или просто ниткой/верёвкой) неполная. Во-первых, в ней нет аналога кабины лифта, которая бы набирала момент импульса. (Да и противовес вы тоже не описали.) Во-вторых, в тросовом космическом лифте максимальное натяжение не в точке крепления к планете/планетоиду, а на стационарной орбите.
Я имел в виду пользу для имиджа, которую потом в некоторых местах можно материализовать, например, через кампании против урезания бюджета, за увеличение государственного финансирования и/или по сбору частного.
Я с таким не сталкивался на сайтах российских научных учреждений. Подумал, что именно обсерватории могут иначе работать, или ситуация недавно изменилась, но тоже не похоже. Зашёл на несколько вебсайтов обсерваторий и не нашёл "магазина по продаже контента", всё больше новости с иллюстрациями или галереи с непонятной лицензией (по умолчанию, видимо, несвободной), хорошо если написано, к кому обращаться, если вдруг что.
Готовый магазин для более полных научных/технических данных (чем изображения) кажется ещё менее вероятным, потому что вещь очень уж нишевая. Заранее заморочиться с хостингом гигабайтов/терабайтов/петабайтов, или сделать специальную пробную версию поменьше ради единичных потенциальных покупателей? А если уж по грантам давать доступ не требуется, и не предвидится прочих преимуществ, то этим почти наверняка не будут заниматься.
Так закрытый контент российских обсерваторий продаётся лучше (может профинансировать сколь-нибудь значительную долю их работы), или это скорее тот случай, когда жалко терять сугубо потенциальную прибыль?
Правда, думается, что в России ещё и вряд ли возможно получить больше государственного или частного финансирования именно за открытые изображения и другие данные. Тогда и от свободного лицензирования обсерватории существенно лучше не станет, а обеспечение доступа нередко ещё и требует дополнительных усилий.
Речь не об импульсе, а о моменте импульса.
Когда лифт не движется и сопротивлением воздуха можно пренебречь, по тросу в равновесном состоянии момент импульса течь не должен.
Вроде бы течение момента импульса по тросу может обеспечить только разница сил натяжения вдоль троса. Поскольку от поверхности до синхронной орбиты сила натяжения возрастает, "точка подвеса" на синхронной орбите для этого должна быть сдвинута от поверхности (немного) вперёд, т.е. по направлению вращения. А поскольку дальше до противовеса она убывает, то противовес должен быть сдвинут (чуть-чуть) назад (против направления вращения) относительно "точки подвеса" на синхронной орбите, если нам нужно подавать момент импульса в ту дальнюю часть троса тоже. Это довольно хитрая конструкция, и не очевидно, как и почему именно она образуется.
Тут возникает вопрос, насколько хорошо у российских обсерваторий получается монетизировать свои изображения (вероятно, риторический, но мало ли).
Открытые данные (в конечном итоге) вроде бы являются практически стандартом для больших научных проектов, финансируемых из бюджетных средств в США, Западной Европе и Канаде. Хотя они не обязательно становятся доступны сразу — поначалу бывает и проприетарный период "только для своих", чтобы мотивировать людей работать над инструментом и первичной обработкой данных, а не только лишь использовать готовые.
Была у нас вроде бы такая школьная олимпиадная задача с упрощённой постановкой (хотя, наверное, она больше годится для университета, чтобы знали начала матана и немного диффуров).
Прочность на растяжение/сжатие — это предел механического напряжения, силы на единицу площади (как давление, но смысл не совсем тот). Можно установить фиксированное механическое напряжение во сколько-то раз меньше предела прочности для надёжности. Изменение силы натяжения (в случае троса) или давления (в случае штанги/башни) должно компенсировать гравитационную и центробежную силы, действующие на участок конструкции. Получается такой диффур:
где A — площадь сечения троса/штанги,
— выбранное механическое напряжение, 
— плотность материала, R — расстояние от центра планеты/планетоида, 
— угловая скорость вращения (предполагая строительство на экваторе). В случае штанги нужно выбирать знак плюс, в случае троса — минус. Решение довольно простое:
Минимальная площадь сечения определяется так, чтобы материал выдержал максимально нагруженную кабину лифта, а в случае троса — ещё и противовес на том конце.
В земных условиях для нормальных материалов максимальная площадь сечения получается очень уж огромной, нужно минимизировать отношение плотности к дозволительному напряжению (пределу прочности).
В процессе подъёма на синхронную орбиту кабина должна приобрести момент импульса. Ну, угловая скорость сохраняется, но момент инерции кабины вокруг оси вращения планеты/планетоида растёт как
.
В случае жёсткой штанги/башни вроде более-менее понятно, что вся конструкция может "забирать" момент импульса у планеты/планетоида, хотя для этого нужна приличная прочность на изгиб (но вроде бы не настолько сильная, как на сжатие/растяжение, т.к. когда лифт не движется, всё раскручено до правильных скоростей и изгибаться не надо).
В случае троса/системы тросов не очевидно. Казалось бы, из-за изгиба троса около кабины против направления вращения силы натяжения троса (как снизу, так и сверху) будут подтягивать кабину в направлении вращения. Соответственно, момент импульса вроде бы будет "течь" к кабине не только снизу, но и сверху. Снизу не проблема, потому что даже у карликовой планеты момента импульса очень много (по крайней мере, пока мы не начинаем поднимать грузы, сравнимые с массой планеты, при этом всё спускаемое можно вычитать). Но сверху только противовес по большому счёту, как ему не потерять момент импульса и соответственно не начать снижаться и/или тормозить?
Скорее уж огромное (релятивистское) давление фотонов, очень часто взаимодействующих с обычной материей (в основном электронами, которые уже взаимодействовали с положительными ионами), мешало гравитационному коллапсу.
А в стандартной космологической парадигме есть ещё и тёмная материя, которая потихоньку сжималась в это время, потому что на неё фотоны влияли намного слабее. Это сжатие было очень медленным, пока в энергетическом бюджете Вселенной доминировало излучение, и стало побыстрее, когда стала преобладать материя (тёмная+обычная). Считается, что после рекомбинации обычная материя стала проваливаться в потенциальные ямы, сформированные тёмной материей, иначе рост структур был бы существенно медленнее.
Маленькая поправка:
Причём ускорение в смысле второй производной масштабного фактора a,
. Если рассматривать относительную скорость расширения (она же параметр Хаббла) 
, то её производная не возрастает даже с космологической постоянной, для этого нужно нечто ещё более экстремальное с 
, что вроде как нарушает null energy condition и ломает многое в квантовых теориях поля.
Сам квадрат параметра Хаббла, согласно другому уравнению Фридмана, просто пропорционален суммарной плотности (в которую нужно включить глобальную кривизну пространства, если она есть).
Насколько я понимаю, make только парсит уже прописанные зависимости, в самом коде он специально не разбирается. Т.е., например, если зависимость от какого-то включённого (#include в C/C++) файла явно не написана, то после его изменения (без модификации основного файла) перекомпиляция не произойдёт, хотя по логике она нужна. Однако как минимум в gcc/g++ и clang есть опция -MMD, которая как раз генерирует такие неочевидные зависимости для make параллельно с компиляцией, и получившийся файл можно включить в Makefile.
С продвинутыми зависимостями дата изменения работает весьма хорошо, и позволяет сэкономить время на не изменённых частях больших проектов. А на крайний случай есть make clean, который должен удалять все результаты компиляции, после него make будет собирать всё заново.
Но если в проекте мало файлов, не нужно выискивать системные библиотеки, аккуратно выставлять опции компилятора и всё такое, то, наверное, можно хорошо обойтись и без make.
P.S. Я как-то написал проверку необходимости сборки (подобно make) для пошаговой обработки файлов данных на Python (потому что у меня рецепты были функциями на Python, и имена файлов я там же генерировал). Сначала тоже использовал дату изменения, но потом понял, что это не подходит, потому что я иногда подставляю более старый файл. Так что перешёл на хэши, и с не слишком большим количеством и размером файлов они работают хорошо.