Программа расчета оптических схем

[Alexey_Smirnov]

Здравствуйте все!

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

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

Если кому интересно - буду рад ответить на письмо или в данной теме.

С уважением, Алексей.

[Дрюша]

Здравствуйте все!

Я реанимировал замороженный в 2003 году проект расчета оптических схем.

А я недавно реанимировал аналогичный свой проект 1993 года. Причём, он уже тогда чего-то считал. А сейчас причесал и адаптировал под русскую локализацию. Хошь под DOS, хошь под WinDOS. На этой конфе она уже лежит.
 https://astronomy.ru/forum/index.php/topic,9001.0.html
Так что, здесь я свой "гоп" сказал - когда уже перепрыгнул.
Но у народа наблюдается интерес близкий к нулю

Хотя, что там у Вас - мне интересно. Хотя бы, чисто спортивно. Не как пользователь и клиент, но как соперник и конкурент.
Так что, давайте. Можно сюда прилепить ZIP (но до 80 Кб). А почта у меня andrrog@yandex.ru .

[Дрюша]

А хотя бы краткий обзор возможностей и применяемых методов - можно?

По  представлению:
- описательная модель (радиусы, толщины, зазоры, прочие параметры сложных поверхностей (какие типы есть); продольная, поперечная аберрация, волновая аберрация и т.п.)
- 2D модель с графическим представлением, масштабирование и т.п.
- 3D модель, разные виды и проекции, произвольное масштабирование, пространственные сечения и т.п.

По моделированию и методам расчёта:
- Расчёты по стандартным формулам, аналитическим и эмпирическим зависимостям.
- Геометрические вычисления: диаметры, расстояния, диафрагмы, бленды, виньетирование и светозащита
- Чисто геометрическая модель оптики - трассировка модельных лучей (угол падения, угол отражения, преломления...)
- Интегрирование волнового фронта, получение реальной дифракционной (интерференционной) картины с учётом аберраций, дифракции, ЦЭ...
- Расчёт коэффициентов пропускания, поглощения и рассеяния. Вычисление числа Штреля.

По оптимизации:
- Никакой.
- Всё что угодно, но только вручную. Наличие вспомогательных функций и средств для организации ручной оптимизации.
- Поиск оптимальных сечений на пучке. Разные критерии (максимальное, среднее, среднеквадр. рассеяние) и сравнение с величиной дифракционного рассеяния (для идеального случая)
- Оптимизация параметров взаимного расположения деталей, зазоров и толщин
- Оптимизация параметров поверхностей всех типов (в частности, радиусы кривизны, эксцентриситеты, коэффициенты разложения...)
- Интегральная оценка качества оптической системы по разным критериям

- Расчёт допусков (на положение (вдоль оси, сдвиг от оси, разъюстировку), радиусы кривизны и прочие параметры оптических поверхностей сложных типов)

[Ernest]

Функциональность ожидается на уровне OSLO.

Вот это по настоящему сильно! Респект и плюс! Я около 5 лет угрохал, чтобы написать один модуль приближающийся по функциональности к тому что на тот момент выдавала OSLO. Помнится это было примерно 20 тыс. строк на модном тогда Фортране ну и гора исписанной математическими выкладками бумаги. А таких модулей в OSLO порядка двух десятков.

[Максим Гераськин]

Строка она того - строке рознь.
Одно дело вписывать строки в событие OnClick, тело которого генерируется IDE, и совсем другое, например - "допуски и посадки" в оптике.
Тут, прежде чем строки появятся, надо еще подумать, что же в них должно быть написано 

[Ernest]

С учетом фортранной одностроковости выходим на 5 строк в день.

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

[Максим Гераськин]

Ну "5 строк" - это в пересчете на паскалеподобный или сиобразный язык

Ну, если begin/end/{/} считать за строки, то у Фортрана есть все шансы. Вполне может и более лапидарным оказаться.

[Дрюша]

Вот ссылка на мою публикацию 2003 года в форуме по поводу математической базы моей программы. Там есть все выкладки.

Да, помню. И даже сам я успел там высказаться. И даже про свою разработку рассказал. Ну да ладно.

Значит, у Вас чисто геометрическая (лучевая) оптика. Понятно. Волновой фронт она вряд ли интегрирует. А именно это мне было бы интереснее.

Но только не очень понятно, зачем всё это? Что Вы конкретно собираетесь считать своей программой? Или кого-то так не устраивает OSLO, что он готов заплатить Вам денежку за новую разработку? Или - что? Ладно, я понимаю, начало 90-х, когда Солнышко светило ярче и травка была зеленее, а сейчас-то чего? Никому ничего не надо. Всего везде - бери. Но уже - "не хочу".

[Дрюша]

А дырка в центре линзы/зеркала предусмотрена? Без неё кассегрен не смоделируешь...

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

Положим, у нас моделируется параболическое зеркало фокусом 1 метр. На него падает модельный лучик света. Где он пересечётся с поверхностью параболоида?

Обычно - в двух точках. Иногда - ни в одной (проходит мимо) или в одной (подходит к ней касательно, это кратный корень). Ну, тут - понятно. Дискриминант <0, =0, >0... Но, вот, если он (лучик) ПАРАЛЛЕЛЕН оси параболоида, то решение физически - одно. Но этим методом оно не находится. Этот случай надо распознавать особо, и подбирать другой метод. Потому что ещё на этапе составления самого квадратного уравнения, при вычислении коэффициентов оного, выскакивает "Divide by zero". Оно и есть. Хотя случай этот совершенно реален.

Ладно. Положим, строгую параллельность оси для параболоида - распознали. А теперь пусть на зеркало падает лучик света под углом примерно 20" к оси. Вполне реальный угол. Я даже не говорю про 1" или 0.5"... Тангенс или синус такого угла имеет величину около 1/10 000. Отклонение такого луча от строго параллельного на метровом расстоянии составит около 0.1 мм. Считать такой лучик "параллельным" оси язык уже не поворачивается. Точность 0.1 мм была бы слишком груба (да и 0.01 мм - пожалуй, тоже). Значит, строго говоря, надо решать через квадратное уравнение. Хорошо, решаем. Ничего особенного. Никакого деления на 0. Но только вот что. Решения у нас получается два. Одно - где-то здесь, рядом. А другое... А оно оказывается где-то в 400 тыс. км. от вершины параболоида. Далеко за орбитой Луны. Но это ещё не всё. Оба решения находятся как  (-b - sqrt(D))/(2*a) и (-b + sqrt(D))/(2*a), где а, b - это коэффициенты, а D-найденный дискриминант. И тут получается, что -b/(2*a) и sqrt(D)/(2*a) очень большие по абсолютной величине. Это где-то примерно по 200 тыс. км. Или около 200 млрд. мм (если считать в мм). И Вы хотите, чтобы эти величины, складываясь или вычитаясь, дали нам доли миллиметра с точностью (ну, хотя бы) до 0.01 мкм??? Ведь именно такая точность нам нужна чтобы получить картинку на уровне дифракции (ну, хотя бы десятикратный запас точности - не помешает!). А теперь вспомним, что дискриминант D был у нас под корнем. Если после извлечения корня получается 200 млрд, то сам он, надо думать, выражается 22-значным числом. Ну, формат с плавающей точкой это пропустит. Но прикиньте, какова это будет точность? Даже расширенная двойная точность (10-байтное представление long double) даёт 18-19 верных десятичных цифр. Ну, иногда - 20. А тут надо 22. И это - если надо в миллиметрах. А если в микронах?

Короче, я к тому, что стандартный "школьный" метод вычислений "в лоб" может выкинуть такие фокусы-покусы...! Что и в страшном сне не приснится! Когда я пытался сделать так сделать у себя, то было очень смешно. Луч света "не замечал" параболоида, а потом вдруг ни с того - ни с сего отражался от какой-то произвольной точки в пространстве, и отскакивал в произвольном направлении. Это навеивало мысли о квантовом туннелировании и тонкой структуре физического вакуума, где иногда ни с того ни с сего вдруг рождаются виртуальные частицы и античастицы, которые окромя всего прочего, могут "отфутболить" модельный луч света (наверное, фотон) в произвольном направлении.

[Ernest]

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

Если Вас теория мало занимает, то просто поищите сводку Федеровских формул прогона луча.

[johnson]

Господа!

Что можно сказать по поводу приведенного скриншота? Есть какие-нибудь мысли?

С уважением.

Пока слишком мало информации.
Дизайн интерфейса- дело вкуса. Чтобы понять удобен он (интерфейс) или нет надо с ним хотя бы немного поработать. На мой взгляд не стоит перегружать интерфейс лишней информацией. Например: зачем нужно окно Object Inspector? Всю необходимую информацию можно задавать в «свойствах проекта», а переключатся между проектами с помощью выпадающего меню «Окно», как это сделано во многих программах. Вкладки «Линзы» и «Зеркала» стоило бы объединить в одну, что бы все было под рукой.
Фон окна проекта, стоит, поменять на какой-нибудь «серый», от белого глаза устают сильнее. И язык интерфейса желательно: русский, мне например так привычнее.
Повторюсь еще раз: дизайн интерфейса- дело вкуса. У других, возможно будут свои предпочтения.

[Дрюша]

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

Если Вас теория мало занимает, то просто поищите сводку Федеровских формул прогона луча.

У меня-то это пройденный этап. Я нашёл для себя выход. Может быть, менее оптимальный чем предлагает Родионов или Федеров, но машина - железная, с неё не убудет! Лично у меня всё свелось к тем же ЧМам. Там и точность контролируется. Я могу убедиться, что она на уровне 10^-9 мм - этого заведомо хватит.

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

Про дизайн. Мне он почти ничего не говорит. Интересно бы посмотреть наполнение главного окна. Оно графическое? Как выглядит система? В 2D или 3D? Или чисто схематически, без отражения реально заданных значений параметров? Или просто заполняется таблица с параметрами оптических деталей и их рабочих поверхностей? А результат трассировки? Как он представляется? А сбоку на него можно посмотреть? А с торца? А оптимальное сечение повыбирать (без пересчёта)?

Про "инспектор проекта" уже сказано довольно правильно. Он бы имел смысл, если бы "проект" строился из множества файлов ("модулей" или как их там ещё называть), и их можно было бы подключать или исключать из проекта... А такой статический набор свойств - совершенно недостоин отдельного окна! Лучше всю площадь экрана (или почти всю) - под главное окно! А множество проектов одновременно (в разных окнах) - это, имхо, было бы излишество.

[Дрюша]

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

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

Может, я не понимаю чего...

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

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

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

Если Вы не видите проблем - это не значит, что их нет. Я уже показал, ГДЕ они конкретно в моём примере. А именно - в огромных расстояниях между решениями (действительными, однозначными, физически существующими). Но если даже сразу отклонить "дальнее" решение (до которого 400 тыс. км), то и ближнее тоже ищется как РАЗНОСТЬ (или сумма величин разного знака) двух огромных величин (около 200 тыс. км или 200 млрд. мм). Помните, где (-b - sqrt(D))/(2*a) и (-b + sqrt(D))/(2*a) То и другое решение получается сложением или вычитанием огромных величин. А трудности с точностью и возможным делением на 0 возникают на этапе вычисления КОЭФФИЦИЕНТОВ квадратного уравнения. Именно они получаются огромными (или бесконечными). А когда квадратное уракнение уже есть - то решить его - как два пальца... Но сперва-то надо его получить! (найти коэффициенты).

А так, я по-хорошему завидую. Программного продукта ещё никто не видел, но сколько интереса вокруг него! Ведь это третья по счёту тема (а может, я каких-то ещё не заметил?) именно по поводу него. Мой же не нужен никому. Даже обидно.

[Hell]

Я согласен протестировать версию вашей программы под LInux будет интересно проверить все ее плюсы и минусы

Пишите на skyobserver@mtu-net.ru буду рад помочь!

[Суворов Владимир]

Времени вкачаете очень много!
Но всем будет  интересно. Наверное написать прогу - эту уже личный вопрос.
Так всегда бывает, что иногда забываешь даже поесть.
Все сидишь и пишешь.
Но награда неизмеримо больше. Но это в конце пути. Желаю удачи.

[tlgleonid]

Хотелось бы на нее посмотреть. Если не сложно, вышлите на адресс: tlgleonid@bank.gov.ua

[Дрюша]

И мне на andrrog@yandex.ru

[Hell]

Пишите на skyobserver@mtu-net.ru будем компилить на Линуксе и проверять все ошибки я вам пришлю
буду ждать !!!!

[Дрюша]

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

Сколь бы прекрасной программа ни была, но без документации она имеет ценность процентов 5 от той, что с ней. Ибо не все закоулки и возможности постижимы (на уровне целесообразности) методом "научного тыка".

Всем заинтересованным сторонам я выслал архивы.

Тестируйте на здоровье!

Я, вроде бы, обозначил себя как заинтересованный, а до меня не дошло почему-то... Ну ладно, может, с середине января будет нечто целостное... Хотя, я бы тоже на каникулах почитал хотя бы описание (если есть). А то потом не до неё будет.

[Hell]

Я уже жду не дождусь вашей программы все библиотеки есть только саму программу вы мне так и не выслали шлите на skyobserver@mtu-net.ru буду рад содействовать!

С уважением Болушков Павел