Roadmap Release 2.0

[philbucher]

Unit Testing

• check if it makes sense to switch to doctest, this framework seems to be more lightweight, esp for compilation times => #76
• port remaining tests from Kratos
• using memcheck also debugs the shell which has some errors. => #93
  Possible solutions:
  • Run valgrind separately: https://stackoverflow.com/a/51266896 (not sure if this can still be combined with -T memcheck)
  • suppress errors from bash (dirty solution)
  • sth custom like e.g. nlohman json does
• include the co_sim_io in two separate files (like I did in Kratos) to make sure all the inline definitions are there => #78
• add matrix build for different versions of python => #86

Functionalities

• split connection_name to make usage easier (probably into name and connection_partner => consider that this has to be given to all the functions. Or maybe return a connection_name that should be used in further calls?) => #65
• Implement Import/Export with objects (e.g. Mesh for enhanced functionalities)
• Implement File-Communication in folder (better prevention of deadlocks with leftover files)
• bring back the Run method => #134
• Expose the CopyCTor of Info to Python => #79
• Make the CopyCTor of Info available in C => #132
• add some data container such that data doesn't have to be copied all the time for Python (probably some thin wrapper around std::vector) => #118
• improve naming of master-slave terminology => #134
• implement working directory
• make ModelPart available in C => #131
• Add check to make sure the versions of CoSimIO on either side are compatible! => #140

Internal

• implement begin & end in DataContainer to make them usable in range-based loops => will not be done as too much effort for too little usage
• implement proper connect for FileComm
• improve error macro such that it behaves like the one in Kratos => #92
• agree on naming convention (solver / software-tool / code / (process))
• since it is very unlikely that we move to C++17 I would seriously consider including the C++11 version of std::filesystem. I think it will be worth it and reduce many problematic cases
  • Otherwise many things become much more difficult (e.g. deadlocks bcs of leftover files from previous runs etc...).
  • Note that this includes windows.h in Win, which can be a bit of an issue since we are header only. => this is only a problem in Win when using the C++ interface and not compiling with C++17.
• investigate why Win CI sometimes timeouts, maybe related to new Connection of FileComm. Check how long the codes wait. => #139 should hopefully solve this (also related: #133)
• Check C-Interface of ModelPart, there some things are not yet clear => @pooyan-dadvand
• do we need identifier for Import/Export of Info and ModelPart? => add it everywhere => detail: what about the name of the ModelPart? Probably doesn't matter... => #123 (always using identifier)
• maybe call the sync-file xxx.sync => then might be clearer. (In the future this has to probably be split into connect & disconnect, bcs during the connection phase more info is exchanged (e.g. number of cores the "other" code runs with), but during the disconnect phase it is only needed for syncing)
• How to copy connection_name in C? => use strcpy (probably in combination with BUFSIZ => should we then limit length of names to prevent overflow?) => #124

Documentation

• go through tutorial and improve if necessary
• Complete the API-documentation
  • C++
  • C
  • Python
• enhance the Python-interface to give the full docs in the interface (e.g. __doc__)
• Document the settings used for each IO method. In the error message when setting is invalid or empty?
• in py-tutorial: Explain how to use different py-versions: https://pybind11.readthedocs.io/en/stable/compiling.html#configuration-variables => #88
• refactor and split up the tutorials to make it better readable and to reduce copy-paste btw languages

[pooyan-dadvand]

Maybe we can have a new import/export modelpart instead of enhancing the mesh one with additional object

[philbucher]

remaining things will be addressed for the next release