NOAA-GFDL/pace

variables contained within data structures

Opened this issue · 2 comments

In the native Fortran code there are many variables stored in the various sub-structures within the ATM datatype. There are separate structures for nesting, inline physics, grid-related quantities, control variables/flags. It makes sense to perform a review of the many variables within the datatypes to ensure we are keeping the bare minimum. This is to ensure we are keeping memory pressure on the various processors we are targeting to a minimum. For example, how often do we use area vs inverse area and does it make sense to keep both.

+1

This can even go further, as the memory available on a device can vary widely and for GPU can be a pretty strong performance killer.

The area vs inverse is the perfect example of a case where on GPU you'd be much better of running the math rather than storing/loading a variable. Going further, one could image that some cached numerics should also live with a "uncached" version where the numerics are ran instead of cached - again to limit memory pressure.