Hacks to core and point_mode to enable unit tests

[djmallum]

Purpose

The purpose of this PR is to start a discussion on point_mode runs in CHM without requiring a mesh. A future version of CHM could have an option to have something like this but not hacky.

Details

The following are changes I made to core.cpp and point_mode to allow the running of a single module within CHM but essentially separetely from it. Manually written mesher file allows fine grained parameter control without needed to deal with built in CHM mesh components.

Currently, to run point_mode one is required to specificy a point in space. In order words, one needs to have a full prepared CHM mesh. These changes allowed for a manually written mesher file and not having to worry about the "mesh" being at a valid grid point.

1073            out.face = _mesh->face(0); 

Takes the first face, and in a 0D (or 1D in the case of vertical processes) face(0) is the only triangle defined in the mesher file.

In point_mode, use of a user defined flag unit_test_new_modules allows for user defined, run specific depends and provides in the constructor and fetching from met files in the run function.

if(unit_test_new_modules)
{
    depends_from_met("SWE");
   provides("swe");
    // and more
};

Note

This point_mode version is made to run modules that don't yet exist in CHM but are in this PR draft.

I intend to include manual mesher file and config file to this PR in the future for clarity.

[Chrismarsh]

Instead of hand crafting a mesh, would it be helpful to have CHM just create a single triangle at the point output lat/lon? Point mode config could then take an additional dict of "face" parameters.

[djmallum]

I've added some example config files to this PR. Files here: https://github.com/djmallum/CHMnew/tree/hacks/unit-testing/test_data/unit-test-example-data

Instead of hand crafting a mesh, would it be helpful to have CHM just create a single triangle at the point output lat/lon?

I think hand writing the .param file is OK since it is hardly more complex than writing a list of parameters in the config (json) file. The part that is not needed is the .mesh file, which could be what you meant by this. Looking at my .mesh file, none of the information there actually matters for the tests I did.

Do you think there are advantages to giving a lat/lon value to CHM?

[Chrismarsh]

Do you think there are advantages to giving a lat/lon value to CHM?

if any of the solar radiation calculation code is used it's critical

What I was thinking was that the .mesh file could be completely removed. It provides nothing of value to the end user in point mode. They could then just provide the param file like you have. The single triangle would be generated from the lat long of the station provided in point mode. But in #112 if we have multiple point we need to define a bigger list of parameters anyway so a hand rolled file is maybe easier. This might be a good addition to pyCHM to have a preprocessing tool to auto build the small mesh centred around all the stations given?

[djmallum]

if any of the solar radiation calculation code is used it's critical

How is the lat/lon accessed in the solar radiation code? It is dissimilar to a normal .mesh parameter? I suspect it is since is appears in a unique location. I tried to find an example but couldn't find one.

IMO, if you want to use the full functionality, you shouldn't be running CHM like this in the first place. It should really only be for running single or small (otherwise unfunctional) groups of modules. Modules that don't NEED CHM to function but cannot run without running CHM (because they are contained to a module).

[Chrismarsh]

It's used for computing the solar parameters

CHM/src/modules/solar.cpp

Line 203 in f9b6557

d.lat = y;

[djmallum]

I think the goal of removing the requirement for a .mesh file is a good one. And generally, its up to the user to make sure they provide the right parameters. Lat-lon might be the only special case in that its parameter is not (a) in .param or (b) in the config section for module specific, domain wide parameters. So if the documentation for this simply emphasized the lat-lot special case I think its ok.