Analyses of the interactions with parallel file systems at scale demonstrate that lfric_atm is not scaling well to large rank counts.
lfric_atm requires significant quantities of data to initialise the model, including configurations, mesh definitions, start dumps & ancillaries.
Some facets of the code base implement simple storage interaction patterns where each rank opens a file as it needs it and obtains the information it requires. This works fine for small rank counts and okay for medium rank counts, but scales badly for large rank counts and ensembles of large rank counts.
This represents a major obstacle to large scale implementation.
Identified issues which are being analysed are (in rough priority order):
Validation
- use branchHere to evaluate calling counts and types using io_trace_intercept
- noting large performance overhead, don't trust nor compare timings
- once I/O patterns are validated, rerun tests to confirm actual timings
Analyses of the interactions with parallel file systems at scale demonstrate that
lfric_atmis not scaling well to large rank counts.lfric_atmrequires significant quantities of data to initialise the model, including configurations, mesh definitions, start dumps & ancillaries.Some facets of the code base implement simple storage interaction patterns where each rank opens a file as it needs it and obtains the information it requires. This works fine for small rank counts and okay for medium rank counts, but scales badly for large rank counts and ensembles of large rank counts.
This represents a major obstacle to large scale implementation.
Identified issues which are being analysed are (in rough priority order):
Validation