Checklist about HQMTool

[andrewwinters5000]

This serves as a meta issue on the interactive HQMTool capabilities and implementation. It follows the "make it work, make it nice" philosophy. The phrase "make it nice" can be interpreted as make the implementation more Julian.

Make it work:

• Incorporate functionality and write corresponding tests Add interactive HQMTool and testing #15
• Update figures in the docs now that boundary curves are labeled in a different way.
• Add example recipe scripts to the examples folders so it is easy for others to try out the new features

Make it nice:

• Improve export and only send out the necessary functions
• Fix the license. Currently year is set to 2010 which is incorrect. Possibly remove license from all files and let the main license cover everything
• Clean up include statements as some are now redundant
• Do not need explicit variable type statements in most functions because they have unique names
• Function names are written in camel case whereas snake case is the Julia standard. Change this globally so, for example, getBackgroundGridSize becomes get_background_grid_size
• Keep the docs consistent with all these updates Update documentation with HQMTool #17
• Convert all the warnings ending in "Try again." to either (i) proper errors with @error such that way we can use @ test_throws ErrorException for testing or (ii) proper warnings with @warning
• If possible, increase the "power" of the generic remove! command to encompass more routines
• Condense all plotting information into a new projectView struct such that the Project manages the model / curves in projectDictionary and the plotting is all managed via projectView
• Multiple dispatch on the curve type in curvePoints(crvDict, N) to remove the if logic
• Exported directory examples_dir() will clash with Trixi if a user wants to use the Trixi and HOHQMesh packages examples_dir() is no longer exported.

Minor stuff:

• Indentation and spacing conventions
• Plotting constants like MODEL and REFINEMENTS in Viz/VizProject.jl little unwieldy. Is there a better way? Now exported for easy user access.

[DavidAKopriva]

The last one is the standard way options are done in C frameworks, using binary add to add options together. Makes it easy from the user end just to add numbers together to combine features.

[andrewwinters5000]

The word unwieldy was not the best to use. What I meant is that these constants are not exported currently so in the demos we can write MODEL but a user playing around in a Julia REPL would need to write HOHQMesh.MODEL. This is something that should be made simpler

[ranocha]

Great tool! I haven't looked at the PR in detail, but I watched another nice demo of @andrewwinters5000 today. You could think about renaming some functions to be in accordance with interfaces from Base. For example, push! and pop! might be the kind of interface used instead of add! and remove!.
Take this with a grain of salt - I haven't really looked at the PR yet.

[DavidAKopriva]

Hi @ranocha. You are assuming that the users will be Julia programmers. Presumably the users could be complete non-programmers, or programmers from other languages who just want to generate a mesh, so terms like push! and pop! have no meaning. User facing routines should be descriptive, usually with a verb plus noun like addCurve, etc. I did push^H^H^H^H add generics (since at the moment there are no good GUI frameworks as far as I can tell) so that a more familiar user could avoid typing so much. But ultimately, all (user facing) commands should be "guessable" and "rememberable".

[ranocha]

But ultimately, all (user facing) commands should be "guessable" and "rememberable".

👍