Численное ядро¶

Параметры Риккати¶

Уравнение Узаделя решается в параметризации Риккати: на каждой частоте/энергии — своя краевая задача (BVP) для 16 компонент.

Riccati (Core/Model/Kernels/Riccati) хранит все 16 компонент (gam11E … gamt22E и их производные dgam11E … dgamt22E) как трёхмерные тензоры формы ``(eN × zN × stepsN)`` — энергия/частота, координата, шаг самосогласования. Хранение именно тензором на все шаги сразу (а не только последний) сделано специально: это даёт OrderParameterHistory и возможность посмотреть/отладить сходимость по шагам постфактум, а не только финальный результат.

Метод: getRiccatiIndices() — возвращает struct, отображающий мнемонические имена компонент (GAM11, GAMT12 и т.д.) на номера строк в векторе решения, который возвращает bvp4c. Смысл — солверы обращаются к решению по имени (idx.GAM12), а не по «магическому числу» 9, что и читаемее, и не ломается, если порядок компонент в ОДУ когда-нибудь изменится.

Функции Грина¶

Core/Model/Kernels/GreenFunctions, общий предок — абстрактный GreenBase: хранит 16 компонент G11E … G44E в том же соглашении (eN × zN), что и Riccati (компоненты объявлены protected — наследники и процедуры обязаны читать их через методы ниже, не напрямую).

Методы базового класса:

Три конкретных представления, каждое — со своим способом вычислить те же 16 компонент:

• RetardedGreenFunction — метод CalculateGreenByRiccati(riccatiTensor, stepIdx) строит запаздывающую функцию Грина из параметров Риккати на заданном шаге самосогласования (обычно последнем). Дополнительно методы FormAnomal() / UpdateAnomal() считают аномальные (синглетную и триплетные) компоненты — они не нужны для плотности состояний, но нужны как физическая интерпретация сверхпроводящих корреляций; метод GetDos(zIdx) — плотность состояний по всем энергиям при фиксированной координате, готовая свёртка через GetGreenMatrix + trace, чтобы не дублировать формулу в вызывающем коде.

• AdvancedGreenFunction — строится из запаздывающей методом CalculateAdvancedGreen: G^A = −σ₃(G^R)†σ₃. Отдельный класс, а не просто формула внутри вызывающего кода, — потому что опережающая функция Грина сама по себе нужна в нескольких местах (в частности, в проводимости) и физически имеет тот же интерфейс (GetGreenMatrix и т.д.), что и запаздывающая.

• KeldyshGreenFunction — из запаздывающей и опережающей, метод CalculateKeldyshGreen: G^K = (G^R − G^A)·tanh(βω/2). Нужна только для проводимости (формализм Келдыша, неравновесная величина).

Проводимость¶

Conductivity (Core/Model/Kernels/Conductivity) — простой контейнер результата без логики: поле ConductFull (zN × oN, комплексная). Сама формула (интеграл по энергии от комбинации запаздывающей/опережающей/ келдышевской функций Грина на энергиях, сдвинутых на ±ω/2) живёт в процедуре SFIEnergyBasedFindConductivity (см. ниже), не в этом классе — класс тут исключительно как типизированное хранилище результата.

Решатели (Core/Solvers)¶

Для каждого представления — набор функций для bvp4c:

Главный узел — процедура самосогласованного цикла (SFIEnergyBasedSelfConsistencyLoopProcedure / SFIMatsubaraSelfConsistencyLoopProcedure, у каждой есть _Parfor-версия для параллельного счёта по энергиям/частотам). На каждом шаге:

1. решает краевую задачу bvp4c для каждой энергии/частоты (независимо друг от друга — отсюда и возможность parfor);

2. собирает результаты в тензор Riccati, строит по нему функцию Грина (RetardedGreenFunction.CalculateGreenByRiccati);

3. пересчитывает Δ(z) — функция SFIEnergyBasedComputeSelfConsistentGap(riccatiTensor, calculation, stepIdx), отдельная от солвера ОДУ, потому что формула щели — интеграл по энергии от аномальной части функции Грина, а не часть самого дифференциального уравнения;

4. проверяет сходимость: относительное изменение Δ(z) между шагами меньше OrderParameterTolerance → цикл останавливается, иначе — следующий шаг (до SelfConsistencySteps).

Пайплайны (Core/Pipelines)¶

RunSFIEnergyBasedPipeline / RunSFIMatsubaraPipeline — верхний уровень, вызывается напрямую или (обычно) через Скриптовый слой (Core/Scripting)/CalculationRunner:

1. настройка логгера (Logger.Setup) — чтобы каждый расчёт имел свой лог-файл, а не общий поток вывода в консоль;

2. создание CalculatedPhysicalProperties, если ещё нет;

3. запуск таймера (Timer) — для CalculationTime в результате;

4. самосогласованный цикл (последовательный или parfor, в зависимости от переданного флага);

5. физические процедуры (см. ниже) — список настраиваемый через необязательный аргумент propertyProcedures: если не передан, используется весь стандартный набор (обратная совместимость с кодом, который вызывает пайплайн напрямую, без скриптового слоя);

6. остановка таймера, запись CalculationTime.

Каждый шаг физических процедур обёрнут в свой try/catch — одна упавшая процедура (например, Conductivity без заданной сетки частот) не мешает досчитать и сохранить остальные.

Физические процедуры¶

Core/PhysicalPropertiesProcedures/SFI/EnergyBased — каждая процедура принимает и возвращает calculation (единообразная сигнатура специально для того, чтобы их можно было выстроить в список и вызывать в цикле, как это делает пайплайн и скриптовый слой), дописывая в CalculatedPhysicalProperties свой результат и выставляя соответствующий флаг в PhysicsPipelineEndState:

Именно этот список процедур виден и настраивается через cfg.Procedures в скриптовом слое — подробности в Шаг 3. Какие величины считать.