daniel-de-vries / openlego Goto Github PK

Some changes to be incorporated:

• The json file with info on the design competence is not required anymore.
• A MDO workflow could be specified completely using a single CMDOWS file (in case only mathematical functions are used).
• Therefore the knowledge base directory is optional.

With the new OpenMDAO version 2.3.0 the special recorders developed in OpenLEGO are not working anymore.

These architectures need some minor updates, such as:

• Inclusion of mathematical functions and testing for correct behaviour.
• Take the function order not from the problemFormulation element in CMDOWS, but from a (to be created) element in the workflow.

The partials package is not listed in setup.py's packages entry. Therefore, it is not included when OpenLEGO is packaged and uploaded to PyPi.

At the moment OpenLEGO provides a LEGOmodel, but does not yet add the driver (optimizer, doe) to the model. A new module in OpenLEGO should take a LEGOmodel and be able to add the driver (and possibly some other options) to the model based on the specifications in the CMDOWS file.

Add monolithic options, such as:

• MDA
• DOE (with and without convergence)
• Optimization without feedbacks to be handled

Calling .values() or .keys() on a dict returns a dictview object which does not support direct indexing: https://stackoverflow.com/a/18552025

This applies to:

• XMLComponent.write_input_file
• LEGOModel.coupling_var_cons

The update from 1.3.4 to 1.3.5 has broken all the test of the SSBJ case. Note that version 0.1.6 of the ssbjkadmos package is required to test this.

I will add more information later.

Once a stable version of openlego has been created, it should be published as a package on PyPI so that installation can be done using pip install openlego

The SSBJ test case has the input, output, and partials xml files in the repo. Please remove the these from the repo, as they should just be created locally by the user using a deploy function.

Tested with Anaconda Python 3.6.

When running the Sellar test problem, the AbstractDiscipline deploy function is failing because the XML files are opened in w-mode while the etree.tostring methods as used by the Sellar problem disciplines are returning byte arrays.

The reason for this is a well-known Python bug (or can we call it a feature?):
https://bugs.python.org/issue10942
https://docs.python.org/3/library/xml.etree.elementtree.html#xml.etree.ElementTree.tostring

Suggest to resolve it by writing a new XML-utils function that makes sure that the output of etree.tostring always is of string type.

The SSBJ database has been used to create different MDO workflows (by Imco). This is a nice benchmark case for all packages involved (KADMOS, CMDOWS, OpenLEGO, OpenMDAO) and should be added to the OpenLEGO test cases.

Two main distributed architectures have to be included:

• Collaborative Optimization
• BLISS-2000

These architectures also still require adjustments in KADMOS/CMDOWS.

In the XMLComponent.read_partials_file function, the tuple key should just be that: a tuple. Currently it is a list, resulting in an "unhashable type: list" error.