Current status of the package?

[henry2004y]

Hi,

Great work here for building the ecosystem! I am impressed with the progress.

I'm wondering about the current status of PySPEDAS.jl vs SPEDAS.jl:

1. Have you reimplemented all the functionalities from SPEDAS?
2. Is PySPEDAS.jl wrapping all the python functions from PySPEDAS? I have very few knowledge of PySPEDAS, but based on my usage experience, the tplot plotting design is horrible. I see that you have a new design for plotting.
3. Will SPEDAS.jl be moved to the JuliaSpacePhysics organization soon?

I have a small collection of functions in SpaceAnalysis.jl, but I stopped adding new stuff there because I feel like nothing is so special about space physics, and my implementations are less general enough to live in a package. That package should be deprecated or rewrote from scratch.

If there's any place that I can contribute, let me know! I would also like to join the JuliaSpacePhysics organization~

[Beforerr]

Hi,

Thanks so much for the kind words and for reaching out — really appreciate your support and interest!

For IDL SPEDAS, not all functionality has been reimplemented yet — the scope is huge and many routines are highly specialized. For Python SPEDAS, though, the situation is much better. Since we have PySPEDAS.jl, all Python functions should be accessible, and the usage syntax is designed to be quite close to native Python. Of course, there may still be some edge cases, but it’s a pretty usable bridge overall.

Yes, I’m in the process of moving SPEDAS.jl to the JuliaSpacePhysics organization. I’m first migrating a few smaller packages to get more familiar with the workflow and make sure everything goes smoothly. We’re still in a fairly early stage, experimenting with some ideas for a cleaner and more Julian design — especially around data handling and plotting. Glad to hear your interest and comments!

Absolutely — contributions are very welcome! And I’d be happy to add you to the JuliaSpacePhysics organization. Also, I’d be interested in your thoughts on SpaceAnalysis.jl — even if parts aren’t general enough yet, there may be reusable components or design ideas worth pulling into the broader ecosystem.

Looking forward to collaborating more!
Best,

[henry2004y]

That's great! We can discuss more at GEM if you are there.

Personally I am more familiar with simulations. Recently I realized that many features I wish to include for analyzing simulation data are already available in spacecraft data analysis packages like PySPEDAS. However, there are some issues when using those directly. For example, from my experience using PySPEDAS:

1. Many tools are designed for one specific space missions. The code base is quite messy.
2. Many python implementations are not efficient. For instance, the wave polarization routine is a bad piece of code. It can be drastically improved even in Python, but I don't want to do that because I know better performance can be achieved in Julia. As you mentioned in the document here, 100x speedup is easily achieved.
3. Space data download module need more careful design.

[Beforerr]

Haha, sadly I’m at SHINE this year instead of GEM 🙂 But I totally agree with your observations — dealing with the IDL and Python SPEDAS codebases was exactly what drove me to start writing these packages. I also hope that by keeping things general and modular, much of the functionality can be reused for simulation work as well as spacecraft data.

Right now I’m thinking of this more as a meta-package that wraps and organizes smaller, more focused packages or submodules. That way, we can reuse core functionalities (like coordinate transforms, time series pre-processing, polarization analysis, etc.) independently across different contexts — simulations, observations, or even synthetic data.

Would love to hear your ideas, especially since you’re coming from the simulation side — your insights could really help shape things!

[henry2004y]

One thing that may want to raise the attention is the license. I just checked that PySPEDAS and SPEDAS are mostly MIT; however, there are certain cases where the licenses are not:

https://spedas.org/LICENSE.txt

Once I re-implemented a piece of code from MATLAB to Julia, and I was told by another collaborator that this is also covered by the license, alongside its constraints.

[Beforerr]

Hi @henry2004y

Thank you for pointing this out and for sharing the link — I appreciate you raising this.

My apologies for the late reply; I only just saw your message. I would appreciate your guidance on this point, as to my understanding I did not use or adapt any proprietary software directly in this work. Could you please advise on what specific licenses or notices you recommend including?

[henry2004y]

Honestly I also have little experience in handling this, but I believe we are mostly fine. Here's the quote from Gemini:

The MIT License and the BSD License (specifically the 2-Clause and 3-Clause variants) are both "permissive" licenses. They are highly compatible. Unlike "copyleft" licenses (like the GPL), BSD does not force you to license your project under BSD. You are free to license your project as MIT while depending on BSD code.

[Beforerr]

Hi @henry2004y , I would also want to ask if it would be okay to list your package, TestParticle.jl, in the core library section of the Julia Space Physics Ecosystem (https://juliaspacephysics.github.io/ecosystem/). I believe this method is of core importance in the field, and I would also like to promote the Julia ecosystem a bit during the upcoming AGU, if that would be appropriate.

[henry2004y]

Yes, I would love to!

Btw, I see now you have a separate package for handling VDFs. That reminds me of a half-baked package I have in Python vdfpy. If this new one you works better I am more than happy to switch. What I want to have in the end is a unified package that can analyze all kinds of distributions (from both observation and simulation data) and link to a dispersion solver for further analysis.

[Beforerr]

Yes, the VDF package was developed with the same long-term goal in mind: to provide a flexible and unified framework that can handle distributions from both observations and simulations. It’s still evolving, but I think it is possible for it to grow into exactly the kind of general analysis you’re describing with careful design.

Thanks for sharing vdfpy. I’d be more than happy to compare and see how the two approaches complement each other. Looking forward to exploring potential synergy between the two efforts.