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 4 Next »

STD:

ecflow used may part 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, it 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.

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.
  • 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.
  • 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. 

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.


  • No labels