Can this repo be built stand-alone?

[edwardhartnett]

Can this repo be built stand-alone?

That will be required for CI to be set up with Travis.

CMake has the capability to build this as part of ufs_weather_model, and also in stand-alone mode.

[edwardhartnett]

@junwang-noaa as mentioned in this old issue, and discussed at the meeting yesterday, it will be necessary to build this repo in stand-alone mode to enable testing.

It's OK if this requires FMS or other libraries like netCDF, but it should not require UFS in order to test fv3atm.

[edwardhartnett]

I would like to work on this, but I am elbow-deep in NCEPLIBS and will be for some time.

@junwang-noaa I highly recommend that this issue be resolved so that fv3atm can be built and tested in stand-alone mode. Then I would encourage all programmers to take a few tests sprints, in which everyone put aside new work for a bit, and wrote unit tests for existing code.

[aerorahul]

@edwardhartnett

This repo can be built as a standalone library -- yes. We already do that. But what will you do with just a library?
The fv3dycore (part of this repo) is linked as a library, as are other components ccpp, gfsphysics, etc.
The fv3dycore can be built as a standalone executable e.g. fv3dycore.x using atmos_model.F90 as the driver. But what would you test with the standalone dycore driver? GFDL does testing of the dycore extensively and with this (and other coupled) drivers.

To drive the "fv3atm" component as a standalone executable e.g. fv3atm.x is essentially what the UFS weather model is.
This already allows for testing the physics suites. I agree these are not unit tests.

I am a bit unclear as to what you wish to accomplish by building this as repo as a standalone "thing". To add tests, I would imagine a lot of tiny programs that test the functionality of individual subroutines in this library (or even subcomponent libraries since fv3atm is a collection of its components) by providing inputs (as simulated by the whole big UFS) and comparing them with baseline expected outputs.
I would imagine you could use this standalone driver as the starting point for writing the individual tests to setup FMS, MPP, domain decomposition etc. Is that your intention?

[edwardhartnett]

@aerorahul yes, you have summarized a great plan for getting unit testing into this code.

Last time I tried to add a unit test, the repo would not build for me, which is why I added this issue. From your post I understand that this has changed? Good! If we can get one test running we can close this issue. Then, next time I want to write a test for some of the fv3atm I/O code, it will be possible.

Developing software without unit tests has been proven to be more expensive, more error prone, and more frustrating for programmers. This is well-understood software engineering. There is no reason to believe that this repo is the exception to this commonplace engineering truism.

All over DC, Boulder, and any other tech hub, programmers are writing unit tests for their code as they write e-commerce systems, actuarial calculations for insurance companies, embedded software in cars, toys, and phones, and most importantly, video games for teenagers. They all do this testing because it is the cheap and reliable way to develop software that always works.

Do you agree with me that fv3atm is at least as important as "Call of Duty 3"?

If so, then let's get started on some unit testing.

[aerorahul]

@edwardhartnett Don't look at me.

[edwardhartnett]

[edwardhartnett]

Apparently this repo still cannot be built stand-alone.

The build systems have painted this repo into a corner where we can't add testing or documentation. How can we fix this?

[arunchawla-NOAA]

@edwardhartnett @aerorahul @junwang-noaa @climbfuji

the PRs related to this issue are either in draft mode or closed. Is this issue still open ?

[edwardhartnett]

Certainly this repo should be able to build and test itself.

I have closed my open PR, but I encourage leaders of the FV3 team to bring their CMake build up to date, including stand alone builds, checking for dependencies and versions, unit testing, CI with GitHub actions, and documentation with doxygen. These process elements will only fall into place when they are regarded as firm requirements.

The progress in the various NCEPLIBS projects demonstrates that this can be accomplished and very much improves quality and speeds future development.