teca_detect_node: porting the DetectNodes function from TempestExtremes to TECA

[amandasd]

Porting the DetectNodes function from TempestExtremes to TECA

[burlen]

I am so pleased with the progress you've made!!!

the user facing variables (those that are exposed via teca algorithm properties) should use snake case, the individual words are separated by '_'. so something like 'thelongvariablename' would become 'the_long_variable_name'. this is for consistency with the rest of teca.

Please factor string parsing code out of the get_upstream_request. If it is the case that the various strings need only be parsed once per run then the results, such as the list of arrays to request, can be cached for reuse rather than being generated as each time step is processed. Note: teca's algorithm properties are designed to handle situations like this where cached data depends on a number of properties. when any property is changed cached data can be cleared forcing a regeneration. You'd override teca_algorithm::set_modified to clear the cached data. The presence of cached values would be tested in get_output_metadata and generated on the first invocation or reused on subsequent invocations.

Before we can merge this we need to factor all of tempest code into it's own library. Let's call this library "TE lite". TE lite will have a CMake based build system and only will compile the sources we make use of, for example src/base and src/nodes into a library. TE lite will export this library and teca cmake will use it by find_package(TELight), if the library is not found the new teca algorithms relying on it will not be built.

TE Lite will not be invoking the tempest's existing makefile based build system from cmake, and instead rely on cmake to compile the library. hint: you can use teca's own cmake library generation code as a template. TE lite will not compile any of the tempest executables. The compiled TE lite library is only to include sources we call directly. It's OK to leave other tempest codes in the repo, but those will not be compiled into the library, and will likely be removed at some point down the line once this project is finished.

The TE lite library will publicly be hosted on the LBL-EESA github and will be a means of us and others, including tempest authors, obtaining and making use of the modifications and improvements we are making should the y be interested in doing so.

Tempest sources have a copyright block at the top of each file. Please add a line at the end of each copy right block in each file that you modify, including the date, your name, and a few words to a sentence or two documenting the modification. It doesn't have to be very detailed. Please make a pass now, to capture what's been done to now and going forward do this incrementally as you work.

Thank you!

[burlen]

Hi! Nice work.

I downloaded and tried it locally and made a few improvements to the cmake/build and regression testing. I made to TELite library itself, so you'll have to fetch those. I flagged a few things in the review, which I realize that you probably inherited.

Would like to see if we can produce cyclone tracks. Toward that end. Here is a tests dataset that has 1 cyclone of each Saphir-Simpson category from tropical storm up to cat 5. In /pscratch/sd/l/loring/tc_test_data/ on Perlmutter.

Would like to see a regression test for the detect_nodes class.

We may want to think about about factor all the inherited code into the TELite library, into a templated function that we call from teca_detect_nodes. We can talk about at the next meeting.

Thank you!

[burlen]

it would be good to test the output of the detector

[taobrienlbl]

I suggest renaming to teca_tempest_tc_detect.cpp since this just implements the TC detector app as we discussed on 11/5/2024