I will need to import and work on few databases containing parameters in bw2, ecoinvent(s) and another db exported from Simapro. While in the past I had used bw2parameters I have seen now the handling of parameters has been also included in bwdata and I am getting a bit confused. what is the workflow now? should I just rely and work with one of the two, both or what? and with which version of the two packages?
thx
Parameters (named variables and formulas stored as strings) are introduced in Brightway2-data version 3.0, which is currently a release candidate. Although we have effectively 100% test coverage and some documentation, I would like to wait a bit before the final release to improve the documentation and make sure that there aren't any bugs that pop up somewhere. That being said, I would feel completely comfortable using the release candidate (along with Brightway2-IO 0.6.RC3, which provides nice ways to specify parameters).
bw2parameters is a library for evaluating a graph of variables and formulas. bw2data is a library for storing, loading, and exporting variables and formulas, tracking when their values are obsolete. They don't compete but instead work together.
Related
I'm new to OpenMDAO and started off with the newest version (version 2.3.1 at the time of this post).
I'm working on the setup to a fairly complicated aero-structural optimization using several external codes, specifically NASTRAN and several executables (compiled C++) that post process NASTRAN results.
Ideally I would like to break these down into multiple components to generate my model, run NASTRAN, post process the results, and then extract my objective and constraints from text files. All of my existing interfaces are through text file inputs and outputs. According to the GitHub page, the file variable feature that existed in an old version (v1.7.4) has not yet been implemented in version 2.
https://github.com/OpenMDAO/OpenMDAO
Is there a good workaround for this until the feature is added?
So far the best solution I've come up with is to group everything into one large component that maps input variables to final output by running everything instead of multiple smaller components that break up the process.
Thanks!
File variables themselves are no longer implemented in OpenMDAO. They caused a lot of headaches and didn't fundamentally offer useful functionality because they requires serializing the whole file into memory and passing it around as string buffers. The whole process was just duplicative and inefficient, since the files were ultimately getting written and read from disk far more times than were necessary.
In your case since you're setting up an aerostructural problem, you really wouldn't want to use them anyway. You will want to have access to either analytic or at least semi-analytic total derivatives for efficient execution. So what that means is that the boundary of each component must composed of only floating point variables or arrays of floating point variables.
What you want to do is wrap your analysis tools using ExternalCodeImplicitComp, which tells openmdao that the underlying analysis is actually implicit. Then, even if you use finite-differences to compute the partial derivatives you only need to FD across the residual evaluation. For NASTRAN, this might be a bit tricky to set up, since I don't know if it directly exposes the residual evaluation, but if you can get to the stiffness matrix then you should be able to compute it. You'll be rewarded for your efforts with a greatly improved efficiency and accuracy.
Inside each wrapper, you can use the built in file wrapping tools to read through the files that were written and pull out the numerical values, which you then push into the outputs vector. For NASTRAN you might consider using pyNASTRAN, instead of the file wrapping tools, to save yourself some work.
If you can't expose the residual evaluation, then you can use ExternalCodeComp instead and treat the analysis as if it was explicit. This will make your FD more costly and less accurate, but for linear analyses you should be ok (still not ideal, but better than nothing).
The key idea here is that you're not asking OpenMDAO to pass around file objects. You are wrapping each component with only numerical data at its boundaries. This has the advantage of allowing OpenMDAO's automatic derivatives features to work (even if you use FD to compute the partial derivatives). It also has a secondary advantage that if you (hopefully) graduate to in-memory wrappers for your codes then you won't have to update your models. Only the component's internal code will change.
I am automating acceptance tests defined in a specification written in Gherkin using Elixir. One way to do this is an ExUnit addon called Cabbage.
Now ExUnit seems to provide a setup hook which runs before any single test and a setup_all hook, which runs before the whole suite.
Now when I try to isolate my Gherkin scenarios by resetting the persistence within the setup hook, it seems that the persistence is purged before each step definition is executed. But one scenario in Gherkin almost always needs multiple steps which build up the test environment and execute the test in a fixed order.
The other option, the setup_all hook, on the other hand, resets the persistence once per feature file. But a feature file in Gherkin almost always includes multiple scenarios, which should ideally be fully isolated from each other.
So the aforementioned hooks seem to allow me to isolate single steps (which I consider pointless) and whole feature files (which is far from optimal).
Is there any way to isolate each scenario instead?
First of all, there are alternatives, for example: whitebread.
If all your features, needs some similar initial step, maybe background steps are something to look into. Sadly those changes were mixed in a much larger rewrite of the library that newer got merged into. There is another PR which also is mixed in with other functionality and currently is waiting on companion library update. So currently that doesn't work.
Haven't tested how the library is behaving with setup hooks, but setup_all should work fine.
There is such a thing as tags. Which I think haven't yet been published with the new release, but is in master. They work with callback tag. You can look closer at the example in tests.
There currently is a little bit of mess. I don't have as much time for this library as I would like to.
Hope this helps you a little bit :)
why we should not use any classes from portal-impl.jar inside your portlet?
In my case, how can I read PropsValues without adding portal-impl to maven dependencies.
I'm using Liferay 6.2
Thanks
#Origineil - in a comment to your question - gave you the alternative of what to do instead of using portal-impl.jar (e.g. use GetterUtil.getBoolean(PropsUtil.get(PropsKeys.SESSION_TIMEOUT_AUTO_EXTEND)); instead of PropsValues.SESSION_TIMEOUT_AUTO_EXTEND.
Why shouldn't you add portal-impl.jar to your project? Well, there are many reasons. First of all: It doesn't work. If you add portal-impl.jar to your plugin, there are quite a lot of spring components in there that would re-initialize - and they'd assume they're in the portal context. They'll be missing other code they're dependent on and you'd basically pull in a lot of Liferay's implementation and dependency code, making your plugin ridiculously big. And the initialization can't be done twice, so it won't even work anyways.
Plus, in portal-impl.jar you'll only find Liferay's implementation details - none of this code is ever promised to be stable. Not only will nobody care if you're depending on it, it'll most likely break your assumptions even on minor upgrades. Of course some components in there are more stable then others, but the basic assumption is a good one.
Liferay's API (that you're encouraged to use) lives in portal-service.jar. This is automatically available to all plugins and it contains the implementation mentioned above. Don't depend on someone's (Liferay's) internal implementation. Rather depend on the published API. If this means that you'll have to implement something again - so be it. It might be slightly less elegant, but a lot more future proof. And if you compare the size of portal-impl.jar to the amount of code that you'd duplicate in the case of PropsValues, you'll see that this single expansion is actually a nobrainer. Don't pull in 30M of code just because you'd rather type 30 characters than 60.
I am new to Haxe.
When I try to convert the following line from C# to Haxe using CS2HX:
Interlocked.Increment(ref this.fieldName);
I get error from CS2HX:
ref/out cannot reference fields, only local variables
Now this makes me wonder - are Interlocked functions at all supported by Haxe - ?
Since I certainly would want to use Interlocked on fields and not on local variables.
Are there any alternative options besides using a lock?
Haxe should now have support for ref/out arguments extended so that fields are accepted too. The updates are in Git. Thanks go to #Waneck!
https://groups.google.com/forum/?hl=en#!topic/haxelang/3E-N93qoU38
CS2HX needs separate modification for that upgrade.
Maybe I will do that later myself, at the moment I have no time for that. I will post a comment here when I have updated CS2HX myself or find out that somebody else did it.
An alternative idea that came from that forum is using one-element array, I think that is pretty good too. Certainly better than using locks.
I'm using nuget (as many of you) a lot for referencing external and internal component-assemblies.
For debugging purposes, it would be nice being able to exchange the nuget-assembly for it's source-code.
Unfortunately, some "core-lib" is used pretty often by the solution itself and also some nuget-referenced packages (used by the sln). Simply removing the reference via VS and adding it's source-project often causes an ambigous relation to the "core-lib", because both (sln and package-src) use the "core-lib" - mostly in different versions.
The only way (I know) to solve that issue is to update all references to the same version (usually, the most actual one). That can be pretty annoying, especially in bigger projects.
Maybe there exists a way to make referencing more flexible - e.g. by using wildcards in the hint-path?
Thanks for all suggestions!
Did you try using symbol packages ? More details # http://docs.nuget.org/docs/creating-packages/creating-and-publishing-a-symbol-package