You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In Phase I it was decided to develop WW4 in C++ in its own repository. The assessment of the model design and architecture focused on principles rather than on details. High-level decisions on design and architecture included: (i) WW4 will move from the WW3 ‘card-deck shuffle” approach to parallel computing to a more traditional domain decomposition approach to enable exascale scalability of the code. (ii) WW4 will maximize code coherence and minimize code coupling as an industry standard for code transparency, maintainability, and as a core approach to code optimization and to performance portability.
Phase II of the project expanded on this as follows: (i) Simplify the modeling system by (i-a) consolidating tools and by not porting obsolescent model options (i-b) focusing the repository on a core wave modeling library, and (i-c) have WW4 work with NetCDF - Zarr files only. (ii) Move away from compile-time option selection to run-time option selection. (iii) Use a YAML based approach for managing user input to WW4. (iv) Use Kokkos based data abstraction as the industry standard for performance portability. The latter is needed as WW4 as a community model needs to be efficient at a broad range of hardware architectures.
We are presently executing Phase III of the project, for which no progress reporting is available yet. At the time of writing this (July 2026), PR #19 defines the present choices made, and an initial architecture. This code provides a high-level template version of the model, focusing on modular code design, logic for processing model input and output (including model output and logging). The present code is centered around three main wave modeling routines addressing model initialization, time stepping and finalization, respectively. The latter design choice is based on WW3 experience as well as on present functional needs for ESMF-based model coupling in WW3.
Questions to answer
In Phase III of the project, these are some of the questions that need to be addressed next to move towards a more complete basic design of WW4. We have organized these questions in the following sub-issues:
With or without the three-routine core design, the next critical design choice is how to deal with the core solver or solvers. Within the solved decision indeed to be made about the grid / propagation scheme, numerical approaches, and the source term options..
In the previous phases of the project we decided to have the WW4 repository focus on the core model as a library, with additional code needed for testing and stand-alone model capabilities only. There are, however, some “grey” areas in this approach.
This section is intended to provide additional information, in particular any code examples or code development for learning and informational purposes, but not intended as an actual proposed addition to WW4.
As mentioned above, the present code and large scale architecture is still up for further review. In that context, it is an example as intended for presentation in this section.
Previous Considerations
In Phase I it was decided to develop WW4 in C++ in its own repository. The assessment of the model design and architecture focused on principles rather than on details. High-level decisions on design and architecture included: (i) WW4 will move from the WW3 ‘card-deck shuffle” approach to parallel computing to a more traditional domain decomposition approach to enable exascale scalability of the code. (ii) WW4 will maximize code coherence and minimize code coupling as an industry standard for code transparency, maintainability, and as a core approach to code optimization and to performance portability.
Phase II of the project expanded on this as follows: (i) Simplify the modeling system by (i-a) consolidating tools and by not porting obsolescent model options (i-b) focusing the repository on a core wave modeling library, and (i-c) have WW4 work with NetCDF - Zarr files only. (ii) Move away from compile-time option selection to run-time option selection. (iii) Use a YAML based approach for managing user input to WW4. (iv) Use Kokkos based data abstraction as the industry standard for performance portability. The latter is needed as WW4 as a community model needs to be efficient at a broad range of hardware architectures.
We are presently executing Phase III of the project, for which no progress reporting is available yet. At the time of writing this (July 2026), PR #19 defines the present choices made, and an initial architecture. This code provides a high-level template version of the model, focusing on modular code design, logic for processing model input and output (including model output and logging). The present code is centered around three main wave modeling routines addressing model initialization, time stepping and finalization, respectively. The latter design choice is based on WW3 experience as well as on present functional needs for ESMF-based model coupling in WW3.
Questions to answer
In Phase III of the project, these are some of the questions that need to be addressed next to move towards a more complete basic design of WW4. We have organized these questions in the following sub-issues:
Issue Top level architecture design #52
With or without the three-routine core design, the next critical design choice is how to deal with the core solver or solvers. Within the solved decision indeed to be made about the grid / propagation scheme, numerical approaches, and the source term options..
In the previous phases of the project we decided to have the WW4 repository focus on the core model as a library, with additional code needed for testing and stand-alone model capabilities only. There are, however, some “grey” areas in this approach.
Additional information
This section is intended to provide additional information, in particular any code examples or code development for learning and informational purposes, but not intended as an actual proposed addition to WW4.
As mentioned above, the present code and large scale architecture is still up for further review. In that context, it is an example as intended for presentation in this section.