I would appreciate it if you could share more about your vision and priorities, as this would greatly assist us in aligning our efforts and working more effectively together.

I have a few questions:

1. Icosaheral Graph: Should we view this as an evolution of the current H3 hexagonal graphs or as a completely new workflow?
2. Integration: Are there any adjustments to our pipeline that we should consider, particularly regarding performance or behavior?
3. Graph Support: Will both graph types be maintained, or is a full transition planned?
4. Model Nuances: Can you provide any additional insights on how the graph processing for AIFS compares with GraphCast?
5. Future Steps: Are there any further updates or benchmarks you have in mind?

Thank you!

One thing to note is AIFS is now public, so it should be easier to see how it works/how it builds its graph and maybe incorporate that here.

1. The icosahedral graph would be a different one from H3, but since H3 is only used to generate the grid points, this should be probably a PR of its own, but to enable generating graphs with either H3 or icosahedral ones. @devsjc I know has done some work on this before.
2. The main adjustment is the graph generation for the inputs/outputs. The behaviour should be the same as it currently is, where models can take in a set of points and output to a set of points.
3. Yes, both types, and ideally other types of graphs in the future supported as well, so it is more to generalize beyond just H3 as a graph generator. Decouple graph generation from model running #76 as some work in that regard, but I didn't finish it. One extension to this, which would also probably be a separate PR from the others, is support the anemoi graphs that AIFS uses.
4. I would recommend looking at the AIFS code that is now public to see how that works.
5. No updates or benchmarks for this one, this would just the graph generation mostly, and then the AIFS model. Since the AIFS model is public, and uses PyTorch, it mostly can be taken from that.

My suggestion with this one would be more to make two PRs, one to add icosahedral grids that is also fast to generate, and one for supporting Anemoi graphs, as put in #102. A different PR to add AIFS could be helpful, but as the model is fully open and in PyTorch already, it is less of a priority.

Thanks for the details! I’ve gone through your comments, and I think breaking this into separate PRs makes the most sense. Here’s how I plan to approach it:

1. Icosahedral Graphs – I’ll add support for icosahedral graph generation, separate from H3, allowing flexibility in graph selection. This will also help generalize the graph generation process.

2. Anemoi Graphs – Since AIFS uses Anemoi graphs, I’ll work on integrating them as another graph option. This will be useful for aligning with AIFS and future models.

3. Anemoi Datasets – I’ll add a data loader for Anemoi datasets, ensuring they work alongside WeatherBench and the ICON datasets on Hugging Face. The goal is to enable seamless training with low-res global + high-res regional models.

I’ll start by reviewing the AIFS model code to understand how it constructs graphs and how best to integrate it. If you have any preferences on implementation details or benchmarks you'd like to see, let me know!

Thanks!

Great! Yeah, that sounds like a good plan

While working on the graph generators, I've identified a few enhancements that could significantly improve the scalability and flexibility of our system. Here are my suggestions:

• Create Integration Tests:
  • Develop tests to ensure that various graph types (e.g., icosahedral, Anemoi) can be used interchangeably within our models. This would help verify that our pipeline is robust and that swapping graph representations doesn't break model performance.
• Implement a Factory Pattern:
  • Consider creating a factory class to produce different graph generators based on configuration. This approach would decouple graph generation from model processing and allow us to easily experiment with various graph representations

I think this may be better suited for a separate PR. I would greatly appreciate your insights on this matter.