New package: Amalthea v1.0.0

[JuliaRegistrator]

• Registering package: Amalthea
• Repository: https://github.com/vdiego28/Amalthea.jl
• Created by: @vdiego28
• Version: v1.0.0
• Commit: 74bd6f644ae4b97cedb879cfdb4f76b41af2a67b
• Git reference: HEAD
• Description: A high-performance, hardware-accelerated fork of Luna.jl. Ported critical physics kernels, adaptive ODE solvers, and multi-threaded sweep queues to a stateless Rust backend—supporting AVX-512, Apple Silicon AMX, and GPU offloading via CUDA and Vulkan with zero-copy FFI interoperability.
• Release notes:

First stable release of Amalthea.jl (previously developed as Luna-Rust.jl),
  a performance-focused fork of [Luna.jl](https://github.com/LupoLab/Luna.jl)
  for simulating nonlinear optical pulse propagation (UPPE/GNLSE). The Julia
  API is fully backwards-compatible with Luna.jl; performance-critical
  kernels are offloaded to a native Rust backend (`luna-rust`) via `ccall`.

  **Added**
  - Native-Rust resident stepper (`RustNativeStepper`/`NativeSim`): the full
    RK45 hot loop runs resident in Rust, eliminating the per-stage Julia
    callback round-trip. Covers mode-averaged, radial, modal, and free-space
    geometries; `RealGrid`/`EnvGrid`; Kerr, plasma (PPT/ADK), and Raman
    nonlinearities; gas mixtures; z-dependent linear operators; shot noise.
    Falls back to the Julia stepper automatically outside this scope.
  - Runtime hardware dispatch: CUDA → Vulkan → AVX-512/Apple AMX → AVX2/NEON
    → portable scalar, including an opt-in GPU-resident backend.
  - Per-kernel Rust acceleration (opt-in): PPT ionisation, time-domain Raman,
    Zeisberger/Marcatili dispersion, QDHT batch transforms.
  - Python bindings (`juliacall`-based, pip-installable).
  - Prebuilt binary releases for Linux, macOS, and Windows, with automatic
    source-build fallback.
  - Cross-platform scan-queue locking, validated on all three platforms.

  **Fixed**
  - `Polarisation.ellipse` angle calculation and other fork-vs-upstream
    parity fixes (see `docs/dev/REVIEW.md`).
  - Shell/command-injection hardening in scan job submission.

[github-actions]

Hello, I am an automated registration bot. I help manage the registration process by checking your registration against a set of AutoMerge guidelines. If all these guidelines are met, this pull request will be merged automatically, completing your registration. It is strongly recommended to follow the guidelines, since otherwise the pull request needs to be manually reviewed and merged by a human.

1. New package registration

Please make sure that you have read the package naming guidelines.

2. AutoMerge Guidelines are all met! ✅

Your new package registration met all of the guidelines for auto-merging and is scheduled to be merged when the mandatory waiting period (3 days) has elapsed.

3. To pause or stop registration

If you want to prevent this pull request from being auto-merged, simply leave a comment. If you want to post a comment without blocking auto-merging, you must include the text [noblock] in your comment.

Tip: You can edit blocking comments to add [noblock] in order to unblock auto-merging.

[goerz]

Luna.jl is still maintained by the Lupo Lab, but it isn't set up to take in a change of this scope (a parallel native backend, a new build/FFI toolchain, hardware dispatch, etc.) through its normal contribution path. Diverging as a fork was the practical way to pursue this direction without blocking on upstream review bandwidth for a change this large.

@chrisbrahms: Can you confirm that a fork is appropriate here? Usually, we like to avoid the registration of forked packages, but of course, if there is a consensus between the maintainer of the original package and the fork that this is the best approach, this is fine

[goerz]

There's also something wrong with the linked documentation... which would be especially important for a v1.0.0 release

[vdiego28]

Thanks for the review, @goerz.

On the fork question: happy to speak to this directly. Amalthea.jl is a strict superset of Luna.jl, not a divergent variant — the full Julia-level API and physics models are preserved and backwards-compatible, so anything that runs on
Luna.jl runs unchanged on Amalthea.jl. What it adds on top is a from-scratch Rust numerical backend for the compute-critical kernels (including a resident native stepper that removes the per-step Julia↔Rust callback round-trip) and a
juliacall-based Python interface. That's a substantial change in build/FFI surface — a new toolchain, hardware dispatch, cross-language bindings — well outside the scope of a normal PR series into the upstream project, which is why we
registered it as an independent fork rather than trying to land it incrementally upstream. The package name, repository, and Project.toml UUID are all distinct from Luna.jl, the original MIT license/copyright notice is preserved in
LICENSE, and both projects are credited in CITATION.cff. Full rationale is in the README's "Relationship to Luna.jl" section: https://github.com/vdiego28/Amalthea.jl#relationship-to-lunajl. @chrisbrahms, flagging this for visibility in
case you want to weigh in, but wanted to make sure the case for the fork stood on its own here.

On the broken docs link: you're right, and thanks for catching it before the merge. Root cause: the gh-pages branch was reset yesterday to bootstrap benchmark-action (unrelated infra change), which wiped every previously-deployed
Documenter version. Since then, the only tag build attempted — v1.0.0 — failed during makedocs on 6 stale @ref cross-references left over from a module rename, so stable/ (and the root redirect the badge points at) was never
regenerated; the root URL now just falls through to benchmark-action's placeholder page instead. The @ref issue itself is already fixed on main (vdiego28/Amalthea.jl@440f368), and dev docs build and deploy
cleanly again (https://vdiego28.github.io/Amalthea.jl/dev/). Since v1.0.0's tag/commit is otherwise correct and shouldn't be moved, we'll cut a follow-up patch release once this comes together so stable docs are live under the same fix.

Will follow up here once that's tagged.

[goerz]

That's a straight-up LLM response, is it not? Please don't do that!

That's a substantial change in build/FFI surface — a new toolchain, hardware dispatch, cross-language bindings — well outside the scope of a normal PR series into the upstream project

I don't think so, or at least that would be for @chrisbrahms to decide. If you did not explore the possibility to contribute to the upstream project before reaching a consensus that a fork would be the most appropriate course of action, that makes this a no-go, in view.

Since v1.0.0's tag/commit is otherwise correct and shouldn't be moved

That's not how it works. Tags for Julia packages should only be created after the registration for the corresponding version has gone through. Usually, this process is automated via TagBot. So, if we move ahead with this at all, you should retrigger the registration with v1.0.0 based on a commit that fixes the issue, or an earlier version if the package is not ready for a 1.0 release yet.

[chrisbrahms]

Hi @goerz ,
Thanks for flagging this up. This PR is the first I've heard about the Amalthea.jl package. Our only previous communication with @vdiego28 was a few small PRs to Luna.jl which I closed because they were obviously entirely LLM-generated (including the summaries). So there certainly is no consensus about this approach.

@vdiego28 is certainly correct to say that these changes are not something we would ever merge into Luna.jl directly. The sheer volume of code is such that we couldn't possibly review it. Nevertheless, copying our code wholesale and renaming the package is not something I'm comfortable with, especially considering that we've never spoken to the author about this approach, and that the whole of "Amalthea" appears to be written by an LLM. (I could be wrong, but I find it unlikely that this was hand-written or even manually reviewed, considering that the first commit on GitHub was only 3 weeks ago and Luna.jl is not a simple package.)

A high-performance hardware-accelerated backend to Luna.jl certainly sounds very cool, and we'd be happy to work with @vdiego28 on this in principle. Translating/extending the numerical backend while keeping the physics the same is also a clear usecase where LLM-generated code can be super useful. In my view the clean way of doing that would be to make Luna.jl extensible with different backends, which we're planning on doing for some things anyway (LupoLab/Luna.jl#313, LupoLab/Luna.jl#400). If nothing else, this would have the advantage of keeping both versions in sync on the physical models.

Copying in @jtravs who co-develops Luna.jl with me--he will probably have an opinion too.

[goerz]

@chrisbrahms Thanks for looking into this! I concur that this fork looks very vibe-coded, and thus may not pass the bar with respect to the guidelines for LLM usage of registered packages. I also don't think that as matter of principle, we should be merging the registration of forks against the wishes of the original maintainer, as long as their objections are reasonable and leave a path forward. In this case, for @vdiego28 to collaborate on contributing the desired feature to the original Luna.jl.

Of course, having a fork to fulfill personal needs (with no restrictions on vibe-coding whatsoever) is perfectly fine, outside of the General registry. Packages can be installed directly from GitHub via Pkg's [sources] feature, and there is also to the option to register it in a LocalRegistry.

I'm inclined to close this as not suitable for registration in General, but I'll get a second opinion from a registry maintainer before doing so…

[vdiego28]

Let me start again, I started this as a project a few months ago when a friend of mine brought my attention to the LUNA.jl package, I read through the most used functions by him, and he told me the pains that he had, like performance issues (that I could only be really aware once I started porting code to Rust) and the hard setting of input parameters, (with that I mean only accepting letters like λ instead of just its spelling).

I started by thinking what I would change and what could be done to speed it up, be that architecturally or instructional level, then I asked heir examples and I tried to understand the back end process as it was the most important part in my opinion and the only one that I would touch.
I must say that I've never contributed or done anything like this for opensource, I am unfamiliar with the process of forking a project and publishing a package, so if I made any mistake I am sorry for that.

I've not touched any of the physics of the project as that is way beyond my pay grade, understanding and knowledge, I just tried to make this a better and bigger version of what LUNA.jl is.

So I understand if @chrisbrahms @jtravs decide to have this version unpublished, I'll keep working on it and make it available through GitHub as long as I can maintain it.

I did use LLM agents to help me port the code, write test, documentation and help me delegate some tasks like those pull requests.

So with all that said, I'll be pending your responses and if you want my help on anything just let me know.

PS. This message was entire written by me with the help of the word suggester on the top of my phone's keyboard.

[goerz]

@vdiego28 Thank you for responding "in person"

I just want to be clear that I don't want to dissuade you from adapting Luna to your needs, with or without LLM support, or to make future contributions to the Julia package ecosystem

So I understand if @chrisbrahms @jtravs decide to have this version unpublished

It wouldn't be exactly "unpublished". You can still develop and use your fork, and others can use it as well. As a shared community resource, being registered in the General registry has a higher bar. Especially with coding agents getting more and more capable, forking existing projects to adapt them to personal needs becomes both easy and worthwhile. I've done it myself. But these are not generally suitable to be published to a wide community. First, because they usually don't end up being supported in the long term, and second, because registering such forks without restrictions would lead to splitting the ecosystem. A user looking to add a dependency for Luna might wonder whether they should add Amalthea instead, and then any issues/PR might go to Amalthea, when they should equally go to Luna. It is preferable to keep Luna as the one package that registered packages can depend on. And it's okay to have an "unregistered package": not everything needs to be in the General registry.

I must say that I've never contributed or done anything like this for opensource, I am unfamiliar with the process of forking a project and publishing a package, so if I made any mistake I am sorry for that.

That's okay... that's not something to be sorry about. The particulars depend on the individual project, so this depends on @chrisbrahms and @jtravs to some extent. But generally, it involves a long-term engagement, with small, focused improvements and discussion through issues or whatever other channels the developers of the package might be using (e.g., the Julia Slack).

Also most people do not enjoy "talking to an LLM", so when you engage in discussion on issues, never just paste the output of an LLM (beyond things like translation, if English isn't your first language).

In this case, I would say use the "vibe-coded" Amalthea as a test bed, and then see what parts can be contributed to Luna, and in what form, in dialogue with @chrisbrahms and @jtravs. This is going to take time and effort – but that's exactly the time and effort that makes registered, human-maintained packages valuable over pure vibe-coding.

[vdiego28]

I don't plan on dropping support any time soon for Amalthea.jl, but if you want you can close this PR without merging.

I have to say even though English isn't my first language, as you probably noticed by my name and writing mistakes. I always say that I wrote, write and will write in every language I speak and I'll ever speak, so sometimes I use a chatbot to check, correct and format my text, even if it is my native language.

I understand English perfectly and I can express what ever I want on English, but I am terribly explaining my self, that's all.

I also plan to add every important change made to LUNA.jl to Amalthea.jl as the front end is entirely loaned of that project and the backend has as a backup the original Julia backend, so it can always run as native LUNA.jl plus the support for named parameters.