Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Long-term vision for the AB? #153

Open
tmillross opened this issue May 7, 2018 · 14 comments
Open

Long-term vision for the AB? #153

tmillross opened this issue May 7, 2018 · 14 comments
Labels
discussion Issues that are discussion topics

Comments

@tmillross
Copy link
Contributor

The AB poster under construction should have a section describing the purpose and goals of the software. Initial research suggests there's a limited amount of prominent information on this topic, leading to this issue. For example the readme states: "The activity browser is a graphical user interface for the Brightway2 advanced life cycle assessment framework" and the docs say: "It extends brightway2 through a graphical user interface (GUI) increasing the efficiency of certain tasks." The first issue in this repo relates to a 'development plan' which also includes some discussion on this.

Is it sufficient to highlight the vision of BW2 and state that AB supports/enables that? If so we could make this even more explicit. But perhaps some aspects of the AB vision are not entirely common with BW2?

I imagine there has been plenty of informal discussion on the long-term intentions e.g. between @cmutel @haasad @cardosan and @bsteubing . Would it be possible to collect these thoughts together here or link me to existing resources that I could collate? Then perhaps we could summarise and include as a paragraph in the readme and/or the software 'Welcome page'. Potential benefits include:

  1. common vision shared between developers (and/or constructive discussion facilitated)
  2. framing and guiding project-management related issues such as this
  3. prioritisation of development efforts (e.g. deciding that an externally requested feature is not aligned with the project goals)
  4. increased clarity for users, watchers and [potential] new contributors regarding project intention. For instance the abstract I wrote for the poster (as shared on Slack) may have been poorly focused (on reducing barrier-to-entry to BW2 for non-coders, rather than optimising time taken for common tasks)
  5. delineate potential overlaps with related projects such as OpenLCA, Bonsai and Lcopt to ensure scarce LCA ecosystem developer efforts are optimally distributed and users can select the tool most appropriate for their needs.

So if I were to try and encompass this as a question, it might be:

In the broadest sense, what does the AB enable once it's 'finished'?
@cmutel
Copy link
Contributor

cmutel commented May 14, 2018 via email

@pjamesjoyce pjamesjoyce mentioned this issue May 28, 2018
Closed
@pjamesjoyce
Copy link

pjamesjoyce commented May 31, 2018 •
edited

Hi folks!

James from lcopt here. I happened upon this discussion a few days ago, and thought I'd chip in on point 5.

  1. delineate potential overlaps with related projects such as OpenLCA, Bonsai and Lcopt to ensure scarce LCA ecosystem developer efforts are optimally distributed and users can select the tool most appropriate for their needs.

But first an important side note/update on lcopt:

Important side note/update on lcopt

Migrating lcopt to bw2parameters is now done

Chris' comment, particularly this bit...

  1. I see huge potential in integrating Lcopt into AB. But I think Lcopt
    needs to be migrated to the parameter handling in bw2data first.

... gave me another poke towards updating lcopt to use bw2parameters... which is now done and merged into the development branch.

lcopt-dev is available as a conda package

Inspired by activity-browser-dev, I've also created a conda package for lcopt-dev which autoupdates from successful Travis builds on the development branch.

You can get/update this version using

conda install -c conda-forge -c cmutel -c haasad -c pjamesjoyce lcopt-dev

#or 

conda update -c conda-forge -c cmutel -c haasad -c pjamesjoyce lcopt-dev

lcopt-dev has some cool new features

In addition to using bw2parameters the dev version has the following new features:

mass_flow_example
(Note: it's a mass flow diagram, not an impact flow diagram like the one in the activity browser)

  • You can now see information about what your externally linked flows (technosphere and biosphere) are by hovering over them in the process diagram

hover example

Thoughts on point 5 (finally)

A brief history of lcopt

Lcopt began life as a cross between a quick way to allow some of the non-LCA experts I work with to create LCA foreground models to describe the processes they were developing (in the form of a flow diagram), and a quick way for me to create LCA models for multiple versions of these processes - by applying different parameter sets to these flow charts.

Originally these LCA models were going to be exported to SimaPro (there's still an 'export to SimaPro' button) for analysis, but as it was already written in Python, it made sense to see if the models could be sent directly to Brightway for analysis as well.

Brightway is a lot quicker and more flexible that SimaPro, so this led to the idea of developing the 'Results' section of lcopt with custom visualisations that I thought would be cool.

At this point it had turned into something that could potentially be generally useful to the LCA community, which is when I submitted it to the Journal of Open Source Software

Long story short, Lcopt began life as Brightway adjacent, rather than being an explicit extension to Brightway.

What is lcopt now?

My vision for lcopt it that it sits in the foreground modelling bit of LCA.

In its current incarnation, lcopt is a handy way for LCA practitioners to create and (to a limited extent) analyse LCA foreground models. It doesn't (or at least shouldn't) have the kind of steep learning curve that SimaPro/GaBi/OpenLCA have (there's no need for a training course!) and doesn't require people to have the kind of Python/coding skills you'd need to jump directly into creating a foreground database in Brightway proper.

Here's a diagram I made for an internal presentation on lcopt I gave a while back which explains where I thought it sat in the LCA ecosystem (full presentation is here in case you're interested).

lca_software_landscape

As far as I can tell (please correct me if I'm wrong!) the Activity Browser was designed to let you you browse existing foreground databases (and background databases), rather than create new ones. It looks like you can technically create a foreground model in the Activity Browser, but it's a bit cryptic (especially having to right click in an empty database to add a new activity!). It also looks like there's no way to add parameters in the Activity Browser.

What next for lcopt (and the Activity Browser)?

I'd be happy for lcopt to become a more integrated part of the Brightway ecosystem.

In terms of how it might complement the Activity Browser, I can see 2 options (at least initially):

  1. Adding some lcopt-style flow chart functionality into the Activity Browser - as a panel/tab? - to graphically explore/edit foreground databases
  2. Adding a button to externally launch lcopt from the Activity Browser

It's probably worth mentioning at this point that I'm developing a couple of extensions/additions to lcopt, one of which has a desktop gui (written in tkinter, not PyQt unfortunately) which has such a button to launch lcopt externally.

That one is called lcopt-cv which is a computer vision extension to lcopt which lets you take a photograph of a hand-drawn flow diagram and automatically generate an LCA foreground model in lcopt.

cv-workflow

The other one is for sharing .lcopt model files in a read only form that you don't need an ecoinvent license to view so you can transparently share your foreground model, parameter sets and results (called lcoptview)

Happy to be part of this discussion and also happy to contribute in future!

@haasad haasad added the discussion Issues that are discussion topics label May 31, 2018
@bsteubing
Copy link
Member

bsteubing commented Jun 6, 2018 •
edited

Hi James,

thanks a lot for your great input here! Your lcopt developments are quite exciting and I think this is exactly the kind of tools that we should continue to develop in the IE community. It would be very nice to link or include lcopt in the AB. This aligns well with two core ideas of the AB:

  • to be community driven
  • to allow for extensions

The needs of users for building LCA models can be quite different. Integrating tools like lcopt into the AB would give the user the possibility to choose the interface that is most useful for a given purpose (e.g. lcopt for modeling parameterized foreground systems). By the way, we are currently also working on improving the foreground modeling capabilities of the AB (as well as a few other things). Originally, I had developed the AB for foreground modeling as well, and there is still the plan to re-integrate my modular LCA framework into the AB (it got lost during one of the major overhauls of the AB: http://activity-browser.readthedocs.io/en/latest/metaprocess_introduction.html).

Implementation

This is what still causes the biggest headache to me: how to practically include extensions / tools / plugins for specific purposes into the AB. Of course, many softwares offer this possibility, but we haven't looked at what this would mean for the architecture of the AB. Ideally, a user would get a slim version of the AB and could then install additional packages.

If installed, it could be included in the AB in a fashion similar to this (thanks @haasad for your suggestion):

try:
    import lcopt
    from .plugins import lcopt_widget
    self.stacked.addWidget(lcopt_widget)
except ImportError:
    pass

As a standalone widget this should certainly work. As for the interaction with the rest of the AB, we'd have to see what is needed for this and how tricky it gets in the details... This would be a great case to test how we can open the AB to accommodate additional packages, so I'd be very interested in trying this.

One of our (inofficial) design principles is to use brightway2 as the underlying LCA engine as much as we can, i.e. so far LCI data for example is handled entirely by brightway. I assume that is similar for many aspects of lcopt and whenever this is the case, changes made through lcopt could be displayed/accessed from the existing AB code and vice versa (then it is just a matter of updating the display information in each window).

Perhaps just as a side note, as you probably know, the AB is partly using web content - mainly HTML/Javascript - that is run through Qt's Webkit classes, so embedding web content is not an issue.

How to continue?

Qt is really a powerful environment, so maybe you'd like to try to develop a PyQt widget for lcopt that we could integrate into the AB as described above?

PS: also congrats on your lcopt-cv - really cool stuff! I'd love to try that at some point...

@tmillross tmillross mentioned this issue Jun 15, 2018
Open
@cardosan
Copy link
Contributor

cardosan commented Jun 16, 2018 •
edited

I cannot agree more to all the points already made.

  • Source code documentation: I myself wanted to contribute in some parts but gave up due to the lack of documentation (going line by line to the codes it is too time consuming) and strongly suggest to, at least from now on, take this aspect seriously and make mandatory (mmhh, do not like imposition....let's say strongly suggested) to put a docstring plus commenting as much as possible the codes (for contributors this helps more than the docstrings in manycases)....if the time will be available It would be good also to this for already developed parts. I have see this is already started in Source code documentation #167

  • Lack of parameters the lack of parameters handling is something important and what I wanted contribute was exactly this, but since @pjamesjoyce already made this in is super cool tool the best might be to try the of (both) lcopt with AB to avoid useless double work and take advantage also of the other nice features like the cool (!) visualizations .

  • Users Tutorial and Documentation : this was already started in Activity Browser Tutorial #158 and I think that, considered the relatively mature level AB reached, this would help to make it more useful and used. For example I will start next autumn a course for MSc on LCA modelling and wanted to only work with open source software and it would certainly be of help to have some material already available for me and, of course, also for others teaching similar things.

@tmillross
Copy link
Contributor Author

tmillross commented Jun 16, 2018 •
edited

a course for MSc on LCA modelling and wanted to only work with open source software and it would certainly be of help to have some material already available for me and, of course, also for others teaching similar things.

From presenting the AB poster at an IE conference last month, we can testify to this as a widespread desire! A number of professors stated an intention to try the AB & BW combo for teaching in the coming years.

@pjamesjoyce
Copy link

Thanks @bsteubing: I'll look into PyQt widgets
You're right in thinking that lcopt uses brightway for pretty much anything complicated (LCA calcualtions, searching databases, and now parameter calculations), so yep in theory you're right that

changes made through lcopt could be displayed/accessed from the existing AB code and vice versa

In practice there might be one issue. Within lcopt the product name and the activity name are different. I know this breaks the graph traversal in @cardosan's bw2temporalis. The AB can read lcopt generated databases no problem, but creating an activity that doesn't produce itself appears to be disabled. This might complicate two-way communication between lcopt and the AB, but it shouldn't be to difficult to work around.

@tmillross: On the teaching front, we're developing a couple of MSc level courses in collaboration with the biotech and chemical engineering departments here at KTH on, essentially, LCA for non-LCA people, using lcopt for the practicals instead of SimaPro - I'll report back on how they go.

@cmutel
Copy link
Contributor

cmutel commented Jun 18, 2018

In practice there might be one issue. Within lcopt the product name and the activity name are different. I know this breaks the graph traversal in @cardosan's bw2temporalis

I wonder why this would be the case - when I worked on graph traversal, it really only looked at the technosphere matrix, and so doesn't even recognize the difference between product and activity (just row and column). It also adjusted for activities that didn't produce 1 unit of their reference product. As far as I understand it, there are some activities in ecoinvent which don't have a reference product (although maybe they have a fake one)... In any case, I don't see any reason that this should break anything in temporalis or otherwise.

@pjamesjoyce
Copy link

pjamesjoyce commented Jun 18, 2018 •
edited

@cmutel more info in the bitbucket issue here
As far as I remember the various graph traversal in bw2analyzer work fine with lcopt generated models.

@cmutel
Copy link
Contributor

cmutel commented Jun 18, 2018 via email

@cardosan
Copy link
Contributor

In practice there might be one issue. Within lcopt the product name and the activity name are different. I know this breaks the graph traversal in @cardosan's bw2temporalis.

The graph traversal traversal of temporalis will in any case need some revamping to make it work better with ecoinvent and upcoming(?) new BW2 API. So just go ahead and will try to work on this later on to make it work as it should and be able to handle all these cases.

@tmillross: On the teaching front, we're developing a couple of MSc level courses in collaboration with the biotech and chemical engineering departments here at KTH on, essentially, LCA for non-LCA people, using lcopt for the practicals instead of SimaPro - I'll report back on how they go.

This is just COOOL! Please keep all of us posted. See also my and @bsteubing's comments in #158, I think your work would perfectly fit.

@pjamesjoyce
Copy link

PS: also congrats on your lcopt-cv - really cool stuff! I'd love to try that at some point...

FYI: I've just added a video to the lcopt-cv docs which explains how it works

@cardosan cardosan mentioned this issue Jun 20, 2018
Open
@haasad
Copy link
Member

haasad commented Jul 20, 2018

I just uploaded a first prototype of lcopt running in the AB. Let me know what you think: #174.

@bsteubing
Copy link
Member

Great work Adrian!

A couple of quick thoughts to this:

  • I don't think the "LCA Setup" tab is the right place to launch lcopt from. I would prefer to treat lcopt as a plugin for the moment, until we decide that it really makes sense to turn it into a core component (that should then also integrate with other AB functionality). How about launching it from the menu bar (e.g. in Windows/Plugins, or in Plugins); Another plugin that I would then like to re-integrate is the modular LCA one from the first AB version
  • Having said this, I think it would be good to keep the AB as lightweight as possible, i.e. load plug-ins on demand; clicking Plugins/lcopt should thus load lcopt in a try...except way (as you suggested previously, see above)

I just pushed a committed a suggestion for this onto your branch... let me know what you think.

@haasad
Copy link
Member

haasad commented Jul 21, 2018

I don't think the "LCA Setup" tab is the right place to launch lcopt from.

I completely agree, at least for the current state of lcopt. But my hope is that lcopt will soon be able to work with any bw-project (@pjamesjoyce already did most of the work towards this by making lcopt work with all ecoinvent versions: pjamesjoyce/lcopt#36). Launching lcopt would then need to be a project-specific action again. But for the moment your solution is much more elegant, I like the idea of the PluginManager.

@pjamesjoyce pjamesjoyce mentioned this issue Sep 20, 2018
Open
@dgdekoning dgdekoning mentioned this issue Dec 16, 2019
Closed
@dgdekoning dgdekoning mentioned this issue Jun 9, 2020
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
discussion Issues that are discussion topics
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@cmutel @tmillross @cardosan @haasad @pjamesjoyce @bsteubing