flamapy / flamapy_fw

This repository hosts the main components of flamapy
4 stars 5 forks source link

Document problems when heading in the project #13

Closed jagalindo closed 3 years ago

jagalindo commented 3 years ago

Generate notes on the issues that developers will face when dealing with the project to be later added to the documentation.

jmhorcas commented 3 years ago

Installation/setup

In Windows 10:

The pysat_metamodel requires the Microsoft Visual C++ 14.0 or greater. This dependency can be download from: https://visualstudio.microsoft.com/visual-cpp-build-tools/ You need to install at least:

However, another error raises and the pysat_metamodel plugin cannot be installed. See trace-windows.txt

In Linux:

Installation works fine, despite an error appears related to python-sat module, but it seems to be magically fixed. See trace-linux-setupb.txt

However, when running one of the entrypoints (main2.py) the error "Plugin not found" appears, but both plugins (fm_metamodel and pysat_metamodel) were installed. See linux-plugin-error.txt

jmhorcas commented 3 years ago

Working with the fm_metamodel

The parent-child relationship

The Relation class is a bit tricky: a feature can have one or more relations with other features. This is very flexible because it allows us to model two important things: (1) arbitrary group cardinalities (a..b), and (2) multiple decomposition type (e.g., a feature can have an "or-group" and a mandatory child).

However, it would desirable to directly access to the parent of a given a feature, but this is not possible with the current information in the feature class. In case a "get_parent()" method is required, I think the best solution for this is having a helper class to avoid modifying the core metamodel.

GermanMT commented 3 years ago

Installation/setup

Linux:

By the moment I only have worked in Linux, following the guide in the core repository and I found the same two problems as jmhorcas. The first problem related in python-sat module, also appear if you try to install the requirements.txt in core repository by the command "pip install -r requirements.txt" with other modules. The problem is in wheel dependence that is not installed in virtual environment, so that setup.py try to install the dependencies directly, this the reason for the magically fix. But this way is very inefficient instead of create a wheel by setup.py bdist_wheel. So the solution is install wheel by "pip install wheel" inside of the virtual environment, and command bdist_wheel must work fine. The second problem seems more complex and now I haven't any idea. I think that module famapy inside in core is being confused with famapy metamodels modules installed.

jmhorcas commented 3 years ago

Support for abstract features

Is there a plan to include support for abstract features? Although it seems to be a trivial characteristic which can be implemented with a simple attribute in the feature class, it affects some analysis operations because abstract features bring up the differentiation between configurations (include abstract features) and products (only include concrete features). This will affect operations like valid product, valid configuration, #products, or #configurations, among maybe others.

jmhorcas commented 3 years ago

Use of the analysis operations

Let us suppose we want to use an operation analysis (e.g., valid configuration) in a specific point of my application: with the current famapy architecture we instantiate the operation and use it directly at such code point of my appplication. However, there is some issues with that:

  1. First, we need access to the feature model (PySatModel object) in that point to perform the operation. But, tipically at such point we have the FeatureModel object (from the other metamodel), so we need to transform first the model every time we apply the operation (too costly). One solution here is to store the transformed model in my application regardless we do not need such PySatModel for anything else.
  2. Although we solve the previous issues, each operation instantiate the appropriate solver (e.g., Glucose) every time we perform the operation, and thus, we need to transform the PySatModel to the clauses-based formula that needs Glucose (too costly again). The solution here is again make some kind of object reuse in memory to avoid those repeated hard glue-code operations.

To solve both issues in my project, temporary, I've created a AAFMsHelper class with different analysis operations without relying on the pugling system. Check https://github.com/jmhorcas/fm_montecarlo/blob/main/famapy/metamodels/fm_metamodel/utils/aafms_helper.py

jagalindo commented 3 years ago

My two cents on the last comment. This is worth a meeting. We had that issue on a previous tool also. The solution I see is to have m2t transformation at the pysat level so we don't have to transform it anymore e.g. a cnf transformation. Also, we need to introduce the staged configurations and those should be applied to be applied or unapplied.

jagalindo commented 3 years ago

Howdy guys, @Virako made a great work with the development of a Makefile that will ease off introductory problems for devs. Now we move to python 3.9, and yes... by now, we are not taking into account windows devs for the automatic mode (see readme.md)