ecFlow's documentation is now on readthedocs!

Please go to https://ecflow.readthedocs.io/en/latest/index.html

  • Created by Unknown User (ma0), last modified on Nov 02, 2020

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

STD

ecflow uses many parts of std library. Originally ecflow used boost::shared_ptr, however for ecflow 5, this was replaced with the equivalent std::shared_ptr.

This was also required because of Cereal.

Std::auto_ptr has been replaced with std::unique_ptr

CEREAL

Is used to provide the client/server serialisations, and uses JSON text. There was an option to use BINARY which is a lot faster. But then we lose the backward compatibility, and more importantly the client/server communication may break due to byte order incompatibility. i.e when client/server are on different hardware.

It highly advisable to subscribe to the CEREAL mailing lists. This allows notifications of upcoming release of CEREAL, any performance improvements. It should be noted that we have already migrated to new version, at least once.

Cereal is embedded into ecflow source code to avoid another dependency.

Currently the latest intel compiler breaks with CEREAL. for more details see:   ECFLOW-1600

BOOST

ecflow uses many parts of the boost libs.

  • program options, provides the command line options for both client and server, in addition also provides the command line help.
  • asio : this provides the client/server communication, it uses CEREAL.
  • python. boost python provides the ecflow python API. The API is documented with SPHINX.
  • file system: use for all file and directory access. Please note that c++17 includes std::file_system. For more details see: https://www.bfilipek.com/2019/05/boost-to-stdfs.html
  • date and time: this is used in all the time base attributes and calendars
  • chrono: used for test timing.
  • test:  used to provide unit tests, and client/server and python tests. There are several hundred tests for client/server/python, however there are no test for the GUI.
  • spirit classic: this is used to provide the trigger expression parsing. This library is now legacy, and needs to be replaced with later boost libs.

It should be noted the boost build(based on bjam) is still used occasionally.  But has been replaced with CMAKE. however, on some systems where we are not allowed to install any packages, it can be still be used to install ecflow client/server/python libs. Only the GUI integration is missing.

Other possible use that were planned but not use, were boost exception. This would automatically add function, line number, etc. At the moment this is done manually. 

Doxygen

Ecflow provides support for doxygen generated documentation via integration with cmake. The main benefit here is to see the class hierarchy. 

SPHINX

At one point all of ecflow documentation was done with sphinx, however when confluence was adopted, we were asked to stop using it. 

The ecflow python API documentation is still provided by SPHINX. However to get documentation into confluence requires some massaging. This conversion was provided by user support.

SSL

Ecflow uses SSL for encrypted communication between the client and server. The cmake build will only use SLL when openssl libs are available on the system. Even when these lib are installed on the system, the user has choice not to use them. It should be noted that SSL enabled client/server carries a small performance penalty. It was added due to external customer request, and it not used internally.


  • No labels