C API cleanup

[nwagenbrenner]

This ticket is to track bugs, inconsistencies, and critical functionality that should be added to the C API.

• NinjaMakePointArmy requires the DEM be passed in as a parameter. This is inconsistent with NinjaMakeDomainAverageArmy and NinjaMakeWeatherModelArmy. It looks like it's done this way because currently makePointArmy requires the DEM as a parameter. We should look into changing this to make it consistent with the other army creation methods. It looks like some changes will be needed in pointInitialization to make this work. See for example https://github.com/firelab/windninja/blob/master/src/ninja/ninjaArmy.cpp#L124C23-L124C77

[masonwillman]

Additional tasks:

• NinjaMakeDomainAverageArmy's arguments will not allow it to run diurnal winds. We could add an additional function for diurnal winds, modified the existing NinjaSetDiurnalWinds function, or something else. We should make sure that we try to stay consistent with how NinjaMakePointArmy and NinjaMakeWeatherModelArmy handle this check.
• NinjaSetPDFOutFlag is exposed, but will fail during runtime. Some of the issue is described here Finish the API #259 (comment).
• NinjaGetWxStations does not have a definition currently. It will also need to be added to the testing files in autotest/api.
• NinjaInitializeNoRegister is not exposed. Stu needs this for applications like Flamstat and Fsim to run properly.

[masonwillman]

The C API has needed to be developed/expanded to continue work on the GUI Redesign. Therefore, we have decided that certain WindNinja functionality should be reexamined for the API.

WindNinja Communications:

• Currently, the ninjaCom class will create class handlers for the different use cases. For example, there is a GUI handler to provide a communication flow to the GUI (see here) and one for the cli (see here).
• For the API, we want to refactor ninjaCom to be more generalized, using only 1 of these class handlers. This handler allows a user to specify what types of messages they want to receive and a FILE* to point to where they want those messages to go. The specification of the messages would be handled by the enums defined here.
• The workflow of a user would be as follows:
  1. Call an API function to set up the communication, includes FILE* and message types
  2. WindNinja uses this information to set up each ninjaCom object for the ninjas
  3. The user then handles how to display or use the messages via the FILE* they passed.

Non-Army Related Functions:

• The ninjaArmy class sets up an army of ninjas. To expose this in the API, we reinterpret cast a handler for ninjaArmy called NinjaArmyH (see here).
• For the API, we want to create a new class called ninjaTools or ninjaArmory that would contain all the tools/weapons that the ninjas in the army need. Examples of tools would be surface or forecast data. This class would exist on the same level as ninjaArmy. A major motivation for this would be the existence of persistent objects for the runtime of the program, like weather model objects.
• The workflow of a user would be as follows:
  1. Call an API function to create a ninjaTools class and store the result.
  2. Pass the ninjaTools class (and other related parameters) to preform a related function, like fetching data.
  3. Handle the return result as normal.

@jforthofer and @nwagenbrenner let me know if I missed anything or misinterpreted something from the discussion.