openLCA Application Documentation

repository·master·Indexed 42 days ago

https://github.com/greendelta/olca-app

Documentation for the openLCA Java-based life cycle assessment (LCA) application. Built on the Eclipse Rich Client Platform (RCP), it includes guides for building distribution packages using Tycho Maven or the uv tool, preparing macOS (.dmg and .pkg) and Windows installers, managing application translations, and configuring the Eclipse RCP target platform and EMF components.

Tokens
16.7K
Snippets
51
Records
79
Agent score
54%

What's inside openLCA

  1. Overview of the openLCA repository structure

    master

    The openLCA repository is a multi-project workspace containing the source code for the openLCA Java application, which runs on the Eclipse Rich Client Platform (Eclipse RCP). The repository is organized into the following sub-projects:

    • olca-app: The main source code for the openLCA RCP application.
    • olca-app-build: Scripts for creating distribution packages for Windows, Linux, and macOS.
    • olca-app-html: Source code for the HTML views used within the application (e.g., start page, report views).
    • olca-refdata: Build scripts for reference databases (units, flows, locations, etc.) packaged with the app.
  2. Understand the openLCA matrix export format

    master

    The openLCA matrix export allows you to export a product system into platform-independent matrices for use in external tools.

    Supported file formats include:

    • CSV: Comma-separated, UTF-8 encoded text files.
    • MS Excel: .xlsx files.
    • Python: Uses Numpy/SciPy formats (.npy for dense and .npz for sparse). A Python export also includes a helper library (lib.py) and a script (main.py) with usage examples.

    Regardless of the format chosen, the set of exported matrices and index files remains the same; only the file extensions change.

  3. Best practices for parameters in internationalized strings

    master

    When you must use variables within a string, follow these patterns to ensure compatibility with different languages:

    1. Avoid colons (:): Colons translate poorly. Use hyphens (-) or parentheses (()) instead.
      • Preferred: M.OpenInEditor + " - " + name
      • Preferred: M.UpstreamTotal + " (" + percentage + "%)"
    2. Avoid pluralization logic: If possible, avoid differentiating between singular and plural words. Use a format like DaysAgo=Day(s) ago to cover both cases.
    // Use hyphens instead of colons
    String label = M.OpenInEditor + " - " + name;
    
    // Use parentheses for values
    String total = M.UpstreamTotal + " (" + percentage + "%)";
    
    // Use neutral pluralization
    // messages.properties: DaysAgo=Day(s) ago
  4. How feature branches and versioning work in openLCA

    master

    openLCA development relies on synchronized branches between the olca-app and olca-modules repositories.

    • The master branch: This branch must always be in sync between olca-app and olca-modules. It should always be stable, buildable, and releasable. Only tested and stable features or bug fixes should be merged here.
    • Feature branches: Large features should be developed in dedicated branches. To maintain synchronization, both olca-app and olca-modules must use the same branch name for the same feature.
    • Feature versioning: When sharing a feature branch version with users for feedback, you can append the branch name to the version number (e.g., 2.0.1-ext-props).
    • Release lifecycle:
      • Development: While master is under development, versions use a SNAPSHOT suffix (e.g., 2.0.1-SNAPSHOT for Maven modules and 2.0.1.SNAPSHOT for the application).
      • Release: Before a release, the suffix is removed.
      • Post-Release: After a version (e.g., 2.1.0) is released and tagged, the master branch version is incremented (e.g., to 2.1.1-SNAPSHOT) and the suffix is re-attached.
  5. Understand the Graphical Editor Model hierarchy

    master

    The graphical model is organized into layers and specific component types:

    Layers

    • PRINTABLE_LAYER: Contains the primary visual elements like the Graph and its components.
    • CONNECTION_LAYER: Contains Links that connect components.

    Core Model Components

    • Graph: The parent canvas (the PRINTABLE_LAYER root) that contains Nodes.
    • Node: A graphical representation of a process, product system, library, or result. Nodes can be maximized (showing IOPanes with ExchangeItems) or minimized.
    • IOPane: A sub-component of a maximized Node that lists input or output flows.
    • ExchangeItem: Represents individual flows within an IOPane.
    • Link: Connects a minimized Node or ExchangeItem to another.
    • GraphConfig: Stores user-selected parameters from the Graph Settings menu.

    Base Model Classes

    • GraphElement: Base class that uses PropertyChangeSupport to notify EditParts of changes.
    • GraphComponent: Provides management for size, location, child addition/removal, and connections.
    • MinMaxGraphComponents: Provides methods for components that can be toggled between minimized (shrunk, children removed) and maximized (expanded, children added).
  6. Use uncertainty distribution matrices

    master

    When exporting with uncertainty distributions, openLCA generates additional matrices for A, B, and C to store distribution parameters.

    Distribution Types (*_utype matrices)

    The *_utype matrices (e.g., A_utype, B_utype, C_utype) encode the distribution type for each cell using the following integer codes:

    • 0: No uncertainty distribution
    • 1: Log-normal distribution
    • 2: Normal distribution
    • 3: Triangular distribution
    • 4: Uniform distribution

    Distribution Parameters (*_u0, *_u1, *_u2 matrices)

    Parameter values are stored in matrices corresponding to the distribution type:

    Distribution*_u0*_u1*_u2
    Log-normalGeometric meanGeometric standard deviation-
    NormalArithmetic meanArithmetic standard deviation-
    UniformMinimumMaximum-
    TriangularMinimumModeMaximum
  7. Understand GEF Actions and the execution flow

    master

    Actions in the graphical editor are derived from JFace Actions and are implemented via GEF. They can be selection-specific or CommandStack-specific.

    Because all changes must pass through the EditPart to ensure model integrity, the EditPart provides the execution capability.

    Example: Execution of 'Minimize All'

    When a user triggers a 'Minimize All' action, the following sequence occurs:

    1. For each targeted MinMaxComponent:
      • A Request(REQ_MIN) is created and forwarded to its EditPart.
      • The EditPart forwards the request to its EditPolicy.
      • The EditPolicy creates (or forwards) a Command.
    2. All individual commands are packed into a CompoundCommand.
    3. The CompoundCommand is executed only if all constituent commands are executable.
    4. The action is completed via the menu click.
  8. How Figures and child rendering work

    master

    Figures are the visual components created by EditParts.

    • Model Synchronization: When a model is modified, it notifies the EditPart via a listener. The EditPart then calls the propertyChange method to refresh the corresponding Figure, connections, or children.
    • Child Hierarchy: An EditPart's children's figures are added to the contentPane of the parent figure. Note that an EditPartA child's figure is not necessarily a direct child of FigureA; it may be a child of FigureA.contentPane.
  9. Understand EditParts and EditPolicy for model manipulation

    master

    In the OpenLCA graphical editor, EditParts act as the controllers. Every model object has a corresponding EditPart managed by a GraphEditPartFactory.

    EditPart Hierarchy

    • AbstractConnectionEditPart: Manages connections between a source and a target GraphComponent.
    • AbstractGraphicalEditPart: Links a model object to its visual Figure.
    • AbstractComponentEditPart: Allows the controller to listen for model changes.
    • AbstractVertexEditPart: Provides methods for managing connections.

    The Editing Workflow

    To modify a model, you do not manipulate the model directly. Instead, you follow this flow:

    1. Create a Request: Define the desired change.
    2. Forward to EditPart: Use the getCommand method to pass the request to the controller.
    3. Dispatch to EditPolicy: The EditPart passes the request to an EditPolicy.
    4. Generate Command: The EditPolicy creates a Command (or a CompoundCommand for multiple changes). It can also delegate or forward requests if an action affects multiple edit parts.
    5. Execute: The command is executed, updating both the model and the view.
  10. How the OpenLCA graphical editor architecture works

    master

    The OpenLCA graphical editor is built using the Eclipse Graphical Editor Framework (GEF), following the Model-View-Controller (MVC) pattern. The architecture separates responsibilities into three distinct layers:

    • Models: Contain the actual data to be displayed (e.g., processes, products, results).
    • Views (Figures): The visual representation of the model's data.
    • Controllers (EditParts): Handle the logic behind user actions and coordinate transformations between the model and the view.

    When a model changes, it notifies the corresponding EditPart, which then refreshes the visual Figure or its connections.

  11. Build distribution packages using Tycho Maven

    master

    As an alternative to the Eclipse PDE Export, you can use Maven with Tycho to build the olca-app plugin and create distributable products for Linux, macOS (Intel and ARM), and Windows.

    Prerequisites:

    1. Java 21 installed and JAVA_HOME set.
    2. Maven 3.9+ installed.
    3. olca-modules must be built and installed locally:
      cd olca-modules
      mvn clean install

    Build Command: Run the following from the olca-app-build directory. For release builds (without the SNAPSHOT qualifier), add the -Prelease flag.

    Output: Distributable products are created in the olca-app-build/build/ directory.

    cd olca-app-build
    # For standard build
    mvn clean verify
    
    # For release builds
    mvn clean verify -Prelease