How to add code in science/physics_schemes/source but exclude it from the lfric_atm build?

[MichaelWhitall]

Hi folks,
I want to add some small bits of fortran code to the lfric_apps repository, that perform simple stand-alone unit tests for parts of the physics code. Having added my fortran files and a bash script to compile the unit-tests under:
science/physics_schemes/source/convection/comorph/unit_tests
I'm now finding that the lfric_apps command-line build fails while trying to analyse the dependencies in the unit test code:

  File "/home/users/michael.whitall/lfric_apps/0941_comorph_refact/vn2.2_comorph_refact/applications/lfric_atm/working/lfric_core/infrastructure/build/tools/dependerator/database.py", line 321, in add_module
    raise DatabaseException(
dependerator.database.DatabaseException: ("Unable to add module 'set_qsat_mod' from 'convection/comorph/interface/standalone/set_qsat.F90': ('Database error: ', IntegrityError('UNIQUE constraint failed: fortran_program_unit.unit'))", None)
make[1]: *** [/home/users/michael.whitall/lfric_apps/0941_comorph_refact/vn2.2_comorph_refact/applications/lfric_atm/working/lfric_core/infrastructure/build/analyse.mk:57: convection/comorph/interface/standalone/set_qsat.t] Error 1
make: *** [Makefile:136: build] Error 2
make: Leaving directory '/home/users/michael.whitall/lfric_apps/0941_comorph_refact/vn2.2_comorph_refact/applications/lfric_atm'

Does anyone know how I can tell the LFRic build system to ignore source files in the unit_tests directory? In the UM this was straightforward; you just set the directories to include and exclude under:
fcm-make/inc/um-atmos-common.cfg
There must be something similar somewhere in lfric_apps but I've so-far failed to find it. Any ideas?

If anyone wants more detail; I'm trying to add the CoMorph standalone unit-test (which has always been in the UM copy of comorph) into LFRic to ensure we keep it after the eventual retirement of the UM. The comorph/unit_tests directory wasn't ported across into lfric_apps with the rest of the UM physics for some reason. I'm trying to put it back again as part of this ticket:
lfric_apps:#941. I've confirmed that the comorph unit test compiles and runs fine from the lfric_apps branch, but the lfric_atm command-line build now won't work...

Cheers!
Mike

[dennissergeev]

I think I ran into a similar problem before - my mistake was forgetting to do fcm add the new Fortran files...

[MichaelWhitall]

Hi thanks Dennis,

I checked and I have done fcm add (and even committed the changes), so its not the same problem.

The problem is that my self-contained unit test contains its own simple versions of things like qsat and ereport (so that the unit test can can be free of external dependencies). But when compiling lfric_atm, the build system throws an error because it finds more than one instance of the qsat_mod module in the source directory and doesn't know which one it should use.

I just need to find the place where you specify which directories the main build system looks in, so I can tell it to ignore the unit_tests directory. Then it will only see the intended primary version of qsat_mod and all will be well. Before the fork, you could specify which files and directories to extract from the UM physics, and just not extract the duplicate files from the unit test. But I'm not sure how to do this now that the UM physics code is already in lfric_apps and doesn't need extracting from anywhere!

[dennissergeev]

Ah makes sense! Yes, this is trickier than I thought!

[iboutle]

Definitely more one for the SSD team, but elsewhere, the unit-test folders exist at the same level in the directory structure as the source folder. So probably if you created science/physics_schemes/unit_tests/convection/comorph/ to hold your code, it would work and not get confused with the source code.

[MichaelWhitall]

Hi thanks Ian :) Yeah I thought about fixing this by moving the unit tests to somewhere outside the source directory, but I don't want to have to do that... Part of the reason I'm trying to add the comorph unit_tests under the existing comorph source directory in lfric_apps is to reduce the number of things I have to change by-hand each time I re-import the comorph directory from the UM to lfric_apps to ensure they're consistent. i.e. I want to keep the UM and LFRic copies as close to identical as possible (excepting the code styling differences but that can all be handled by the styling script so not a problem).

Also as it stands, the build script for the comorph unit test assumes it is sitting in the comorph source directory structure to be able to find all the source files it wants. If I have to move the unit test to some other location it will require more complexity to tell it where to find the comorph source (and if that has to be different between the UM and LFRic, that's another thing I have to remember to change each time I re-import!)

There must be a file somewhere in the LFRic build system that specifies which directories to look in for source files for lfric_atm. I just need to find it...

[yaswant]

Not an answer to your question, but can I ask why your tests deviate from pfunit framework? https://curly-memory-j58e8q8.pages.github.io/how_to_use_it/testing/unit_testing.html

[MichaelWhitall]

Hi Yaswant :) Simple answer is that I have never heard of the pfunit framework until now! (and my unit test likely predates it). I wrote the comorph unit test back in the early days of comorph development (~2018). I've kept and maintained it ever since because its really useful just as it is. It consists of a fortran program wrapper (to set test inputs to comorph, run it, and print outputs to a python file), a simple bash script to run the compile, and local versions of a couple of routines that are called from comorph but not part of comorph (e.g. qsat). This setup means the unit test has no dependencies at all on external code, libraries, frameworks etc. And I'm keen to keep it that way :)

[MatthewHambley]

I've had a quick look at this change it it looks more like an integration tests than unit tests. It appears that you have programs which are run and the output interrogated. This is the pattern integration tests take.

If you want information on how such tests are supported check out the documentation: https://curly-memory-j58e8q8.pages.github.io/how_to_use_it/testing/integration_testing.html

You will find detailed some infrastructure which supports the writing of such tests.

[MichaelWhitall]

Awesome thanks Matthew,

OK then yes, its an "integration" rather than "unit" test (sorry for my complete ignorance of modern software engineering lingo!)
Bringing my comorph standalone tests under the modern framework for such things in LFRic is really beyond the scope of my current ticket though (the purpose of lfric_apps:#941 is just to keep the lfric_apps copy of the comorph code-base consistent following changes in the UM copy; adding extra changes to the comorph source directory on the LFRic side that aren't in the UM copy would defeat the object of trying to keep the two consistent for now!)

It was pointed out to me on Monday offline that I can always just use ifdefs to exclude the comorph standalone source from the LFRic build (and I can put them consistently in both UM and lfric_apps copies). So I think I'll just do that for now :)