Remove fv_core.res.nc file in util/tests

Question

Remove fv_core.res.nc file in util/tests

Opened this issue 6 months ago · 5 comments

After the merging of PR #36, most tests will read in the ak and bk coefficients from netcdf files stored off-site for the CI. The only exception will be test_restart_fortran where the pressure coefficients are read in from /util/tests/data/c12_restart/fv_core.res.nc. For consistency, test_restart_fortran should be modified to also read in the ak/bk values from a netcdf file stored off-site. With this change, the fv_core.res.nc file will no longer be necessary and can be removed from pace, which would make pace only more perfect.

Answer 1 · 2024-01-30T16:58:36.000Z

Thanks for opening up this issue. The question becomes do we still need to save the ak/bk values to a restart file when we now require an input file with values to initialize the model?

Answer 2 · 2024-02-02T15:40:00.000Z

One problem that comes to mind is if we want to use the npz_rst (restart regridding) functionality, or if restarting an idealized test that sets ak and bk internally.

We can remove the on-line restart regridding capability from PyFV3, and have pre-processing tools take care of regridding restarts to new vertical (as well as horizontal) resolutions.

For idealized tests that create ak/bk online, perhaps the test should be responsible for creating files for this purpose? Or perhaps idealized tests should follow ak/bk created off-line also?

Answer 3 · 2024-02-02T16:33:07.000Z

An added component for this that we are running into now is that ETA levels are used in Grid computation which has been moved down to the middleware (NDSL). The logic behind this is that we want the middleware to come with "battery-included" for our common models (e.g. FV3-based models for now). This might mean, that the calculation/import might have to move down from pyFV3.

Answer 4 · 2024-02-05T13:33:14.000Z

One nice thing about Python is that you can load individual modules relatively easily. We could make the eta level calculation an exposed API in pyFV3 for use by the middleware layer.

…

On Fri, Feb 2, 2024 at 11:33 AM Florian Deconinck ***@***.***> wrote: An added component for this that we are running into now is that ETA levels are used in Grid computation which has been moved down to the middleware (NDSL). The logic behind this is that we want the middleware to come with "battery-included" for our common models (e.g. FV3-based models for now). This might mean, that the calculation/import might have to move down from pyFV3. — Reply to this email directly, view it on GitHub <#55 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMUQRVA54U6XABZQVYJU4JDYRUIM5AVCNFSM6AAAAABCRSNO7GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRUGIZDENRSGM> . You are receiving this because you commented.Message ID: ***@***.***>

Answer 5 · 2024-02-05T14:35:40.000Z

Well if it is technically true, I wouldn't go that path. Keeping a strict direction in import mechanism (e.g. NDSL > pyFV3) will retain conceptual and code sanity. Though I do agree that some components might have strange positions in the tech stack, it will also impose on us conceptual discussions, which in my experience are always a good thing.

For example here it seems that the ak/bk & level calculation have multiple use cases and a catch-all API seems to emerge depending on where you need need them to come from